-
Notifications
You must be signed in to change notification settings - Fork 28
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #169 from cloudbees-days/cloudbees-cdro-compliance
update workshop
- Loading branch information
Showing
9 changed files
with
1,169 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
21 changes: 21 additions & 0 deletions
21
labs/cloudbees-cdro-compliance/content/labs/01_pre-reqs.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| --- | ||
| title: "Pre-requisites" | ||
| chapter: false | ||
| weight: 2 | ||
| --- | ||
|
|
||
| Welcome to the workshop. | ||
|
|
||
| --- | ||
| <link rel="stylesheet" href="../styles/spinner.css" /> | ||
|
|
||
| ## Registration | ||
|
|
||
| <div id="content"> | ||
| <div class="spin"></div> | ||
| </div> | ||
| <noscript> | ||
| <p>Javascript is required for this form to work.</p> | ||
| </noscript> | ||
|
|
||
| <script type="module" src="../scripts/pre-reqs.js"></script> |
184 changes: 184 additions & 0 deletions
184
labs/cloudbees-cdro-compliance/content/labs/03_basic-release.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,184 @@ | ||
| --- | ||
| title: "Basic release" | ||
| chapter: false | ||
| weight: 3 | ||
| --- | ||
|
|
||
| One of the primary objects in the CloudBees CD/RO application is the release. This is where you can map out the whole delivery process for a given software release. | ||
|
|
||
| With a release pipeline in place you can be certain that all the operations occur in the correct order every single time. | ||
|
|
||
| ## Creating a release from a template | ||
|
|
||
| When you're first logged in you'll see something that looks like this. | ||
|
|
||
|  | ||
|
|
||
| This is where you'll see all the release across everyone's projects. You can filter this down using the set of filters at the top. We'll come back to this in a minute. | ||
|
|
||
| First we'll go to the **Service Catalog** which you'll find in the top navigation. | ||
|
|
||
|  | ||
|
|
||
| The service catalog is a collection of pre-made content that can be instantiated by anyone with permissions. | ||
|
|
||
| To get started with this lab you'll click create on the **1. Basic Release** item. | ||
|
|
||
|  | ||
|
|
||
| Fill out the form with your desired release name. For your convenience in finding yours you may want to name it something like `my-username Release`. | ||
|
|
||
| With that complete, you can navigate back to the release list by opening the "burger" menu at the top left and navigating to the **Release Orchestration > Releases** item. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| If you'd like to make it easier to keep track of your specific release, you can use the project filter at the top. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| Now you can click on the name of your release, and it'll bring you into the release. | ||
|
|
||
|  | ||
|
|
||
| A release is made up of a bunch of tasks spread across multiple stages. In this case, you can see that your release has 3 different stages: **Release Readiness**, **Quality Assurance**, and **Production**. | ||
|
|
||
| You can have as many stages as you want. Typically, you'll have a stage to represent each of the different environments that are involved in the release process. In the next couple of labs we'll dive into the environment modeling capabilities. | ||
|
|
||
| Let's look at what steps are already setup in this release. | ||
|
|
||
| ## Release overview | ||
|
|
||
| In the **Release Readiness** stage there are two data gathering tasks. | ||
|
|
||
| 1. Grab the changelogs from the application source code in GitHub | ||
| 2. Pull the static code analysis results of the latest SonarQube scan | ||
|
|
||
| If you were using a tool like Jira for issue tracking, you would likely also want to pull information about the stories surrounding this release. | ||
|
|
||
| Next is the exit gate on the **Release Readiness** stage. You can expand this by clicking the dark gray box on the right side of the stage. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| This is the exit gate where the criteria to allow the release to continue past this stage is defined. The criteria can be both automatic and manual. | ||
|
|
||
| Here you can see there is one called **No Code Smells** which is pulling information from the **Get latest SonarQube scan results** task and ensuring there were no code smells. | ||
|
|
||
| Like the exit gate, you can also define an entry gate on each stage to specify the criteria for when the release can enter the stage. | ||
|
|
||
| Next there are two stages, **Quality Assurance** and **Production** that each currently have a single task. These tasks are mocking where we'll eventually add a deployment step. Currently, they are just a simple `echo "Replace me"` command. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ## Running the release | ||
|
|
||
| Now that you've looked through your current release, go ahead and run it. Over on the right side of the screen, you'll see a floating green button with a play icon in it. | ||
|
|
||
|  | ||
|
|
||
| Once you click **Start release** a modal will pop up where you could pass in parameters and select which stages you want to run. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| Let's leave the default options and run through all the stages. Go ahead and click **Run**. | ||
|
|
||
|  | ||
|
|
||
| This will take you to your release run. It should quickly execute. You should see that everything has turned green and each stage will have a checkmark showing that it was successfully completed. | ||
|
|
||
| You can check out the summary for each stage by clicking the **Summary** button towards the top of each stage. | ||
|
|
||
|  | ||
|
|
||
| To do a deeper dive on the data from a given task you can click on the task. You can see the logs as well as the properties that are pulled from any external tools. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ## Making a change | ||
| Our release pipeline isn't going to be winning any awards at the moment. Besides the fact that the deployments are just mocked out at the moment, there aren't any sort of checks between the QA deployment and the production deployment. | ||
|
|
||
| Currently, if the deployment into QA failed, it would still go on to attempt the deployment into production. That is not what we want! | ||
|
|
||
| What we'll do is add an approval to the entry gate into the **Production** stage to ensure the production deployment only occurs when it is safe to do so. | ||
|
|
||
| _Note: You may want to get to a point where there are no manual approvals, everything is fully automated. This is easy to do. You need to add validators like we have on the exit gate of the **Release Readiness** stage which pull data from your tests. The key is to make sure that you have sufficient tests that you feel confident in deploying to production._ | ||
|
|
||
| To add this entry gate, expand the entry gate panel on the left side of the **Production** stage. | ||
|
|
||
|  | ||
|
|
||
| You can call this entry gate whatever you would like. In the screenshot you can see it called `Manual approval`. Then select the rule type of **Approval**. | ||
|
|
||
|  | ||
|
|
||
| Then click on the **Define** button to configure the approval. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| Go ahead and assign this approval to yourself. You can add a message if you'd like as well. | ||
|
|
||
| You may notice when you go to assign yourself that you can assign both users and groups. Often times you'll want to assign a specific team rather than a person. You can specify the minimum number of users who need to approve it as well to ensure more than one set of eyes is looking at it. | ||
|
|
||
|  | ||
|
|
||
| Go ahead and click **OK**. | ||
|
|
||
| With that you've successfully made your release a bit more practical. | ||
|
|
||
|  | ||
|
|
||
| ## Rerunning the release | ||
| With your new change in place, go ahead and kick off your release again. | ||
|
|
||
| After having run your release before, you'll notice the floating green "play" button is now blue and a vertical dots icon. You can click **Run pipeline** to kick it off with a fresh set of settings, or you can do **Previous run** to reuse whatever settings you used previously. | ||
|
|
||
| In our case, we just used the default settings so either one will work identically. | ||
|
|
||
|  | ||
|
|
||
| The release will start running and you'll quickly see that it is paused while waiting for the manual approval. | ||
|
|
||
|  | ||
|
|
||
| Before responding to the approval, let's take a quick look at a separate view where you can always see which releases are waiting on you. On the top bar, go ahead and click on the **My work** item. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| This list will have an always up-to-date list of all the manual tasks requiring your input. | ||
|
|
||
| Alright, now back to the release run. If you didn't open the **My Work** page in a new tab, you can click on the **Go to** arrow on the right side of the list item to bring you back. | ||
|
|
||
| Go ahead and click on the approval where it says **Response required**. Then click the item in the dropdown to bring up the approval modal. | ||
|
|
||
|  | ||
|  | ||
|
|
||
| And with that approval complete, your release should successfully complete. | ||
|  | ||
|
|
||
| ## Automatic auditing | ||
|
|
||
| Before we move on to the next lab, let's take a quick peak at the automatic auditing that has happened on this release. | ||
|
|
||
| Go to the actions menu in the top right of the release run and click on **Audit Reports**. | ||
|  | ||
|
|
||
| Here you can see all the information that is automatically gathered for each and every release run. You don't have to do anything to configure this, it just happens automatically. You can export this and share it with your auditors. | ||
|
|
||
|  | ||
|  | ||
|  | ||
|
|
||
| And with that, we're on to the next lab where we'll take a look at the basics of **Deployment Automation**. | ||
|
|
||
|
|
||
|
|
||
| <script defer src="../scripts/replacer.js" type="module"></script> | ||
|
|
Oops, something went wrong.