| 0-rogue-cluster/README.md | ●●●●● patch | view | raw | blame | history | |
| 1-the-manual-menace/README.md | ●●●●● patch | view | raw | blame | history | |
| 2-attack-of-the-pipelines/README.md | ●●●●● patch | view | raw | blame | history | |
| 3-revenge-of-the-automated-testing/README.md | ●●●●● patch | view | raw | blame | history | |
| 4-an-enslaved-hope/README.md | ●●●●● patch | view | raw | blame | history | |
| 5-non-functionals-strike-back/README.md | ●●●●● patch | view | raw | blame | history | |
| 6-return-of-the-app-monitoring/README.md | ●●●●● patch | view | raw | blame | history | |
| 7-the-cluster-awakens/README.md | patch | view | raw | blame | history | |
| 8-the-last-unicorn-dev/README.md | ●●●●● patch | view | raw | blame | history |
0-rogue-cluster/README.md
@@ -8,7 +8,7 @@ </p> ## Cluster Requirements Learners will create 3 to 4 project namespaces running lightweight NodeJS app * 2 and a MongoDB in up to three of these namespace (dev, test, uat for example). The learners ci-cd namespace will house GitLab, Nexus and Jenkins as well as any slave pods used by jenkins. Learners will create 3 to 4 project namespaces running lightweight NodeJS app * 2 and a MongoDB in up to three of these namespaces (dev, test, uat for example). The learners ci-cd namespace will house GitLab, Nexus and Jenkins as well as any slave pods used by Jenkins. - Jenkins requires 5Gi of Persistent Storage and 4Gi of RAM - GitLab requires 2Gi of storage and 2Gi of RAM @@ -18,7 +18,7 @@ ## Cluster Access - Learners are in LDAP and can access cluster via `oc login` - Learners have access to LDAP bind credentials to be able to auth against gitlab - Learners have access to LDAP bind credentials to be able to auth against GitLab ## User privileges - Learners will require privileges to run SCC containers ie GitLab - Learners will require privileges to run SCC containers i.e. GitLab 1-the-manual-menace/README.md
@@ -1,5 +1,5 @@ # The Manual Menace > In this exercise learners will use Ansible to drive automated provisioning of Projects in Openshift, Git, Jenkins and Nexus. > In this exercise learners will use Ansible to drive automated provisioning of Projects in OpenShift, Git, Jenkins and Nexus.  @@ -10,7 +10,7 @@ #### Why is config-as-code important? * Assurance - Prevents unwanted config changes from people making arbitrary changes to environments. No more Snowflake servers! * Traceability - Commiting config as code means a user has approved and changes can be tracked. * Traceability - Committing config as code means a user has approved and changes can be tracked. * Phoenix Server - Burn it all to the ground and bring it back; exactly the way it was! _____ @@ -32,16 +32,16 @@ ## Big Picture > The Big Picture is our emerging architecture; starting with an empty cluser we populate it with projects and some ci/cd tooling. > The Big Picture is our emerging architecture; starting with an empty cluster we populate it with projects and some ci/cd tooling.  _____ ## 10,000 Ft View > This exercise is aimed at the creation of the tooling that will be used to support the rest of the Exercises. The highlevel goal is to create a collection of project namespaces and populate them with Git, Jenkins & Nexus. > This exercise is aimed at the creation of the tooling that will be used to support the rest of the Exercises. The high-level goal is to create a collection of project namespaces and populate them with Git, Jenkins & Nexus. If you're feeling confident and don't want to follow the step-by-step guide these highlevel instructions should provide a challenge for you: If you're feeling confident and don't want to follow the step-by-step guide these high-level instructions should provide a challenge for you: 2. Clone the repo `https://github.com/rht-labs/enablement-ci-cd` which contains the scaffold of the project. Ensure you get all remote branches. @@ -52,7 +52,7 @@ 2. Use the templates provided to create build and deployment configs in `<your-name>-ci-cd` for. Templates are on a branch called `exercise1/git-nexus` && `exercise1/jenkins`: * Nexus * GitLab * Jenkins (using an s2i to pre-configure jenkins) * Jenkins (using an s2i to pre-configure Jenkins) 2. Commit your `enablement-ci-cd` repository to the GitLab Instance you've created @@ -121,10 +121,10 @@ 3. Open the `inventory/host_vars/projects-and-policies.yml` file; you should see some variables setup already to create the `<YOUR_NAME>-ci-cd` namespace. This object is passed to the OpenShift Applier to call the `templates/project-requests.yml` template with the `params/project-requests-ci-cd` parameters. We will add some additional content here but first let's explore the parameters and the template 3. Open the `params/project-requests-ci-cd` and replace the `<YOUR_NAME>` with your name to create the correstponding projects in the cluster. 3. Open the `params/project-requests-ci-cd` and replace the `<YOUR_NAME>` with your name to create the corresponding projects in the cluster.  3. Let's add two more param files to pass to our template to be able to create a `dev` and `test` project. 3. Let's add two more params files to pass to our template to be able to create a `dev` and `test` project. * Create another two params files `params/project-requests-dev` & `params/project-requests-test`. On the terminal run ```bash touch params/project-requests-dev params/project-requests-test @@ -263,8 +263,8 @@ * `<BIND_USER_PASSWORD>` is the password used when querying the LDAP * `<YOUR_DOMAIN>` is the domain the LDAP is hosted on * `<LDAP_HOST>` is fqdn of the LDAP server * `<LDAP_DESCRIPTION>` is the description to be used on the sign-in header for GitLab eg "Name LDAP Login" * `<GITLAB_ROOT_USER_PASSWORD>` is the root user for GOD access on the GitLab instance eg password123 * `<LDAP_DESCRIPTION>` is the description to be used on the sign-in header for GitLab e.g. "Name LDAP Login" * `<GITLAB_ROOT_USER_PASSWORD>` is the root user for GOD access on the GitLab instance e.g. password123 * `<GITLAB_URL>` is the endpoint for gitlab. It will take the form `gitlab-<YOUR_NAME>-ci-cd.apps.<ENV_ID>.<YOUR_DOMAIN>.com` 4. Create another object in the inventory `inventory/host_vars/ci-cd-tooling.yml` file to run the build & deploy of this template. Add the following and update the `namespace:` accordingly @@ -288,7 +288,7 @@ #### 3b - Commit CI/CD 4. Navigate to gitlab (if you have just skipped straight to this step; ask your tutor for the URL). You can login using your cluster credentials using the LDAP tab 4. Navigate to GitLab (if you have just skipped straight to this step; ask your tutor for the URL). You can login using your cluster credentials using the LDAP tab  4. Once logged in create a new project called `enablement-ci-cd` and mark it as internal. Once created; copy out the `git url` for use on the next step. @@ -305,7 +305,7 @@ git config --global user.name "Your Name" ``` 4. Commit your local project to this new remote by first removing the existing origin (github) where the ansible project was cloned from in the first steps. Remember to substitute `<GIT_URL>` accordingly with the one created for your `enablement-ci-cd` repository a moment ago. 4. Commit your local project to this new remote by first removing the existing origin (github) where the Ansible project was cloned from in the first steps. Remember to substitute `<GIT_URL>` accordingly with the one created for your `enablement-ci-cd` repository a moment ago. ```bash git remote set-url origin <GIT_URL> ``` @@ -327,7 +327,7 @@ git checkout exercise1/mongodb params/mongodb templates/mongodb.yml ``` 4. Open `enablement-ci-cd` in your favourite editor. Edit the `inventory/host_vars/ci-cd-tooling.yml` to include a new object for our mongodb as shown below. This item can be added below the jenkins slave in the `ci-cd-tooling` section. 4. Open `enablement-ci-cd` in your favourite editor. Edit the `inventory/host_vars/ci-cd-tooling.yml` to include a new object for our mongodb as shown below. This item can be added below the Jenkins slave in the `ci-cd-tooling` section. ```yaml - name: "jenkins-mongodb" namespace: "{{ ci_cd_namespace }}" @@ -349,7 +349,7 @@ git push ``` 4. Apply this change as done previously using ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace and checking if it is there! 4. Apply this change as done previously using Ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace and checking if it is there! ```bash ansible-playbook apply.yml -e target=tools \ -i inventory/ \ @@ -366,7 +366,7 @@ ```bash git checkout exercise1/jenkins templates/jenkins.yml ``` The Jenkins template is essentially the standard persistent jenkins one with OpenShift. The Jenkins template is essentially the standard persistent Jenkins one with OpenShift. 5. As before; create a new set of params by creating a `params/jenkins` file and adding some overrides to the template and updating the `<YOUR_NAME>` value accordingly. ``` @@ -377,7 +377,7 @@ JENKINS_OPTS=--sessionTimeout=720 ``` 5. Add a `jenkins` variable to the ansible inventory underneath the jenkins-mongo (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. 5. Add a `jenkins` variable to the Ansible inventory underneath the jenkins-mongo (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. ```yaml - name: "jenkins" namespace: "{{ ci_cd_namespace }}" @@ -388,11 +388,11 @@ ``` This configuration, if applied now, will create the deployment configuration needed for Jenkins but the `${NAMESPACE}:${JENKINS_IMAGE_STREAM_TAG}` in the template won't exist yet. 5. To create this image we will take the supported OpenShift Jenkins Image and bake into it some extra configuration using an [s2i](https://github.com/openshift/source-to-image) builder image. More information on Jenkins s2i is found on the [openshift/jenkins](https://github.com/openshift/jenkins#installing-using-s2i-build) github page. To create an s2i configuration for jenkins, check out the pre-canned configuration source in the `enablement-ci-cd` repo 5. To create this image we will take the supported OpenShift Jenkins Image and bake into it some extra configuration using an [s2i](https://github.com/openshift/source-to-image) builder image. More information on Jenkins s2i is found on the [openshift/jenkins](https://github.com/openshift/jenkins#installing-using-s2i-build) GitHub page. To create an s2i configuration for Jenkins, check out the pre-canned configuration source in the `enablement-ci-cd` repo ```bash git checkout exercise1/jenkins-s2i jenkins-s2i ``` The structure of the jenkins s2i config is The structure of the Jenkins s2i config is ``` jenkins-s2i ├── README.md @@ -419,14 +419,14 @@  Why does Jenkins have Blue Balls? More can be found [on reddit](https://www.reddit.com/r/programming/comments/4lu6q8/why_does_jenkins_have_blue_balls/) or the [jenkins blog](https://jenkins.io/blog/2012/03/13/why-does-jenkins-have-blue-balls/) 5. Before building and deploying the Jenkins s2i; add git credentials to it. These will be used by Jenkins to access the Git Repositories where our apps will be stored. We want Jenkins to be able to push tags to it so write access is required. There are a few ways we can do this; either adding them to the `template/jenkins.yml` as environment Variables and then including them in the `params/jenkins` file. We could also create a token in GitLab and use it as the source secret in the jenkins template. But for simplicity just replace the `<USERNAME>` && `<PASSWORD>` in the `jenkins-s2i/configuration/init.groovy` with your ldap credentials as seen below. This init file gets run when Jenkins launches and will setup the credentials for use in our Jobs in the next exercises 5. Before building and deploying the Jenkins s2i; add git credentials to it. These will be used by Jenkins to access the Git Repositories where our apps will be stored. We want Jenkins to be able to push tags to it so write access is required. There are a few ways we can do this; either adding them to the `template/jenkins.yml` as environment Variables and then including them in the `params/jenkins` file. We could also create a token in GitLab and use it as the source secret in the Jenkins template. But for simplicity just replace the `<USERNAME>` && `<PASSWORD>` in the `jenkins-s2i/configuration/init.groovy` with your LDAP credentials as seen below. This init file gets run when Jenkins launches and will setup the credentials for use in our Jobs in the next exercises ```groovy gitUsername = System.getenv("GIT_USERNAME") ?: "<USERNAME>" gitPassword = System.getenv("GIT_PASSWORD") ?: "<PASSWORD>" ``` <p class="tip"> Note in a residency we would not use your GitCredentials for pushing and pulling from Git, A service user would be created for this. Note in a residency we would not use your GitCredentials for pushing and pulling from Git, a service user would be created for this. </p> 5. Checkout the params and the templates for the `jenkins-s2i` @@ -453,7 +453,7 @@ Note in a residency we would not use your GitCredentials for pushing and pulling from Git, A service user would be created or a token generated. </p> 5. Create a new object `ci-cd-builds` in the ansible `inventory/host_vars/ci-cd-tooling.yml` to drive the s2i build configuration. 5. Create a new object `ci-cd-builds` in the Ansible `inventory/host_vars/ci-cd-tooling.yml` to drive the s2i build configuration. ```yaml - object: ci-cd-builds content: @@ -476,7 +476,7 @@ git push ``` 5. In order for Jenkins to be able to run `npm` builds and installs we must configure a `jenkins-build-slave` for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. These slaves can take a time to build themselves so to speed up we have placed the slave within openshift and you can use the following commands to be able to use them in your project. 5. In order for Jenkins to be able to run `npm` builds and installs we must configure a `jenkins-build-slave` for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. These slaves can take a time to build themselves so to speed up we have placed the slave within OpenShift and you can use the following commands to be able to use them in your project. ```bash oc project <YOUR_NAME>-ci-cd ``` @@ -498,7 +498,7 @@ 5. This will trigger a build of the s2i and when it's complete it will add an imagestream of `<YOUR_NAME>-ci-cd/jenkins:latest` to the project. The Deployment config should kick in and deploy the image once it arrives. You can follow the build of the s2i by going to the OpenShift console's project  5. When the Jenkins deployment has completed; login (using your openshift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job 5. When the Jenkins deployment has completed; login (using your OpenShift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job ### Part 6 - Jenkins Hello World > _To test things are working end-to-end; create a hello world job that doesn't do much but proves we can pull code from git and that our balls are green._ @@ -511,10 +511,10 @@ 6. On the build tab add an Execute Shell step and fill it with `echo "Hello World"` . 6. Run the build and we should see if pass succesfully and with Green Balls!  6. Run the build and we should see if pass successfully and with Green Balls!  ### Part 7 - Live, Die, Repeat > _In this section you will proove the infra as code is working by deleting your Cluster Content and recreating it all_ > _In this section you will prove the infra as code is working by deleting your Cluster Content and recreating it all_ 7. Commit your code to the new repo in GitLab ```bash 2-attack-of-the-pipelines/README.md
@@ -48,7 +48,7 @@ 2. Deploy a `MongoDB` using the provided template to all project namespace. 2. Create 2 pipline with three stages (`build`, `bake`, `deploy`) in jenkins for `develop` & `master` branches on the `todolist-fe` such that: 2. Create 2 pipelines with three stages (`build`, `bake`, `deploy`) in Jenkins for `develop` & `master` branches on the `todolist-fe` such that: * a `Build` job is responsible for compiling and packaging our code: 1. Checkout from source code (`develop` for `<yourname>-dev` & `master` for `<yourname>-test`) 2. Install node dependencies and run a build / package @@ -263,7 +263,7 @@ * `./server/api` is where the api's controller, data model & unit test are stored. * `./server/mocks` is a mock server used for when there is no DB access * `./server/config` stores our Express JS config, header information and other middleware. * `./server/config/environment` stores enviromnent specific config; such as connectivity to backend services like MongoDB. * `./server/config/environment` stores environment specific config; such as connectivity to backend services like MongoDB. * `./tasks` is a collection of additional `Grunt` tasks which will be used in later exercises * `Grunt` is a taskrunner for use with Node.JS projects * `package.json` contains the dependency list and a lot of very helpful scripts for managing the app lifecycle @@ -323,7 +323,7 @@ ### Part 2 - Add configs to cluster > _In this exercise; we will use the OpenShift Applier to drive the creation of cluster content required by the app such as MongoDB and the Apps Build / Deploy Config_ 4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move into this `.openshift-applier` directory and you should see a familiar looking directory structure for an ansible playbook. 4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move into this `.openshift-applier` directory and you should see a familiar looking directory structure for an Ansible playbook. ``` .openshift-applier ├── README.md @@ -515,7 +515,7 @@ * Add string parameter type * set the Name to `BUILD_TAG`. This will be available to the job as an Enviroment Variable. * You can set `dev-todolist-fe-build.` as the default value for ease when triggering manually. * The description is not required but a handy one for reference would be `${JOB_NAME}.${BUILD_NUMBER} of previous build eg dev-todolist-fe-build.1232` * The description is not required but a handy one for reference would be `${JOB_NAME}.${BUILD_NUMBER} of previous build e.g. dev-todolist-fe-build.1232` <p class="tip"> NOTE - Don't forget to include the `.` after `dev-todolist-fe-build` in the Default Value box. </p> 3-revenge-of-the-automated-testing/README.md
@@ -36,7 +36,7 @@ Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. ### Testing Bananalogy Explanation of Mocha and js test syntax through Bananalogy! Imagine for a moment; we're not building software but creating a bowl of fruit. To create a `Bunch of Bananas` component for our fruit bowl we could start with our tests as shown below. Explanation of Mocha and JS test syntax through Bananalogy! Imagine for a moment; we're not building software but creating a bowl of fruit. To create a `Bunch of Bananas` component for our fruit bowl we could start with our tests as shown below.  * `describe` is used to group tests together. The string `"a bunch of ripe bananas"` is for human reading and allows you to identify tests. * `it` is a statement that contains a test. It should contain an assertion such as `expect` or `should`. It follows the syntax of `describe` where the string passed in identifies the statement. @@ -73,7 +73,7 @@ > The goal of this exercise is to add a new component to the application using TDD to create and validate it's behaviour. The User story we have been given is as follows: *As a doer I want to mark todos as important so that I can keep track of and complete high prirority todos first* *As a doer I want to mark todos as important so that I can keep track of and complete high priority todos first* _Acceptance Criteria_ - [ ] should be doable with a single click @@ -111,7 +111,7 @@ 2. You should see an output similar to the following. The above command has run a test suite for every `*.spec.js` file. The table generated in the terminal shows the code coverage. We're going to be focusing on the unit tests for now.  2. Repeat the same process for `todolist-api` and verify that all the tests run. If you have an ExpressJS server already running from previous exercise; you should kill it before running the tests. The `mocha` test suite will launch a dev server for running the tests. There are 2 Api test files: `todolist-api/server/api/todo/todo.spec.js` & `todolist-api/server/mocks/mock-routes.spec.js` for our API and the Mocks server. 2. Repeat the same process for `todolist-api` and verify that all the tests run. If you have an ExpressJS server already running from previous exercise; you should kill it before running the tests. The `mocha` test suite will launch a dev server for running the tests. There are 2 API test files: `todolist-api/server/api/todo/todo.spec.js` & `todolist-api/server/mocks/mock-routes.spec.js` for our API and the Mocks server. ```bash cd todolist-api ``` @@ -119,7 +119,7 @@ npm run test ``` 2. Navigate to your instance of jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.lader.rht-labs.com/`. 2. Navigate to your instance of Jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.lader.rht-labs.com/`. Click on `dev-todolist-fe-build` and then click the `configure` button on the left-hand side.  @@ -303,7 +303,7 @@ }); ``` 3. Next we need to update the `server/config/seed.js` file so that the pre-generated todos have an important propety. Add `important: true` below `completed: *` for each object. Don't forget to add a comma at the end of the `completed: *` line. 3. Next we need to update the `server/config/seed.js` file so that the pre-generated todos have an important property. Add `important: true` below `completed: *` for each object. Don't forget to add a comma at the end of the `completed: *` line.  3. With your changes to the Database schema updated; re-run your tests. @@ -366,7 +366,7 @@ git push -u origin feature/important-flag ``` 3. Let's get our tests running by executing a `--watch` on our tests. This will keep re-running our tests everytime there is a file change. It is hany to have this running in a new terminal session. 3. Let's get our tests running by executing a `--watch` on our tests. This will keep re-running our tests everytime there is a file change. It is handy to have this running in a new terminal session. ```bash npm run test -- --watch ``` 4-an-enslaved-hope/README.md
@@ -6,7 +6,7 @@ There are a number of ways pipeline as code can be achieved in Jenkins. * The Job DSL Plugin - this is a slightly older but very functional DSL mechanism to create reusable pipelines. Create a `groovy` file to run Jenkins Domain Specific Language to create jobs, functions and other items. In Jenkins; you then can execute this file which will build all of the config.xml files needed for each Job. * The Scripted Pipeline - The scripted pipeline introduced the Jenkinsfile and the ability for developers to write their jenkins setup as groovy code. A repo with a Jenkinsfile in it's root can be pointed to by Jenkins and it will automatically build out each of the stages described within. The scripted pipeline is ultimately Groovy at it's core. * The Scripted Pipeline - The scripted pipeline introduced the Jenkinsfile and the ability for developers to write their Jenkins setup as groovy code. A repo with a Jenkinsfile in it's root can be pointed to by Jenkins and it will automatically build out each of the stages described within. The scripted pipeline is ultimately Groovy at it's core. * The Declarative Pipeline - This approach looks to simplify and opinionate what you can do and when you can do it in a pipeline. It does this by giving you top level `block` which define sections, directives and steps. The declarative syntax is not run as groovy but you can execute groovy inside script blocks. The advantage of it over scripted is validation of the config and lighter approach with requirement to understand all of the `groovy` syntax _____ @@ -49,17 +49,17 @@ git checkout feature/jenkinsfile ``` 2. Open up your `todolist-api` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. The highlevel structure of the file is shown collapsed below. 2. Open up your `todolist-api` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. The high-level structure of the file is shown collapsed below.  Some of the key things to note: * `pipeline {}` is how all declarative jenkins pipelines begin. * `pipeline {}` is how all declarative Jenkins pipelines begin. * `environment {}` defines environment variables to be used across all build stages * `options {}` contains specific Job specs you want to run globally across the jobs e.g. setting the terminal colour * `stage {}` all jobs must have one stage. This is the logical part of the build that will be executed e.g. `bake-image` * `steps {}` each `stage` has one or more steps involved. These could be execute shell or git checkout etc. * `agent {}` specifies the node the build should be run on eg `jenkins-slave-npm` * `agent {}` specifies the node the build should be run on e.g. `jenkins-slave-npm` * `post {}` hook is used to specify the post-build-actions. Jenkins declarative provides very useful callbacks for `success`, `failure` and `always` which are useful for controlling the job flow * `when {}` is used for flow control. It can be used at stage level and be used to stop pipeline entering that stage. eg when branch is master; deploy to `test` environment. * `when {}` is used for flow control. It can be used at stage level and be used to stop pipeline entering that stage. e.g. when branch is master; deploy to `test` environment. 2. The Jenkinsfile is mostly complete to do all the testing etc that was done in previous exercises. Some minor changes will be needed to orchestrate namespaces. Find and replace all instances of `<YOUR_NAME>` in the Jenkinsfile. Update the `<GIT_USERNAME>` to the one you login to the cluster with; this variable is used in the namespace of your git projects when checking out code etc. Ensure the `GITLAB_DOMAIN` matches your git host. ```groovy @@ -100,7 +100,7 @@ 2. Fill in the Git settings with your `todolist-api` GitLab url and set the credentials as you've done before. `https://gitlab.apps.lader.rht-labs.com/<YOUR_NAME>/todolist-api.git`  2. Set the `Scan Multibranch Pipeline Triggers` to be periodic and the interval to 1 minute. This will poll the gitlab instance for new branches or change sets to build. 2. Set the `Scan Multibranch Pipeline Triggers` to be periodic and the interval to 1 minute. This will poll the GitLab instance for new branches or change sets to build.  2. Save the Job configuration to run the intial scan. The log will show scans for `master` and `develop` branch which have no `Jenkinsfile` so are skipped. The resulting view will show the `feature/jenkinsfile` job corresponding the only branch that currently has one. The build should run automatically. @@ -322,7 +322,7 @@ -e "filter_tags=zap" ``` 3. Head to https://console.lader.rht-labs.com on Openshift and move to your ci-cd project > builds. You should see `jenkins-slave-zap` has been built. 3. Head to https://console.lader.rht-labs.com on OpenShift and move to your ci-cd project > builds. You should see `jenkins-slave-zap` has been built.  #### 3b - Arachni Scan @@ -343,7 +343,7 @@ - arachni ``` 3. Update the `jenkins-slave-arachni` files `SOURCE_REPOSITORY_URL` to point to your gitlab's hosted version of the `enablement-ci-cd` repo. 3. Update the `jenkins-slave-arachni` files `SOURCE_REPOSITORY_URL` to point to your GitLab's hosted version of the `enablement-ci-cd` repo. ``` SOURCE_REPOSITORY_URL=https://gitlab.apps.lader.rht-labs.com/<GIT_USERNAME>/enablement-ci-cd.git SOURCE_CONTEXT_DIR=docker/jenkins-slave-arachni @@ -363,14 +363,14 @@ git push ``` 3. Run the ansible playbook filtering with tag `arachni` so only the arachni build pods are run. 3. Run the Ansible playbook filtering with tag `arachni` so only the arachni build pods are run. ```bash ansible-playbook apply.yml -e target=tools \ -i inventory/ \ -e "filter_tags=arachni" ``` 3. Head to https://console.lader.rht-labs.com on Openshift and move to your ci-cd project > builds. You should see `jenkins-slave-arachni`. 3. Head to https://console.lader.rht-labs.com on OpenShift and move to your ci-cd project > builds. You should see `jenkins-slave-arachni`.  _____ @@ -383,7 +383,7 @@ Jenkins Pipeline Extension - Add an extension to the pipeline that promotes code to UAT environment once the master job has been successful. - Use a WAIT to allow for manual input to appove the promotion - Use a WAIT to allow for manual input to approve the promotion Jenkins e2e extension (blue/green) - Add a step in the pipeline to only deploy to the `test` environment if the e2e tests have run successfully against which ever environment (blue or green) is not deployed. 5-non-functionals-strike-back/README.md
@@ -4,15 +4,15 @@  ## Exercise Intro Non functional testing provides valuable insights into code quality and application performance. Often overlooked but usually one of the most essential types of testing, non functional testing types can include, but are not limited to Non-functional testing provides valuable insights into code quality and application performance. Often overlooked but usually one of the most essential types of testing, non-functional testing types can include, but are not limited to - Performance Testing - Security testing - Static Code analysis - Vulnerability scanning There are many tools out there for supporting these testing types but often they are left to the end of a delivery. Many traditional projects will leave Performance testing or security sign off to a few weeks before Go Live. This raises the question of what do we do if things do not pass these tests? Do we hold off the Go Live or accept the risk. In most cases we can learn earlier if things will be show stoppers and more importantly we can automate them. There are many tools out there for supporting these testing types but often they are left to the end of a delivery. Many traditional projects will leave Performance testing or security sign off to a few weeks before Go Live. This raises the question of what do we do if things do not pass these tests? Do we hold off the Go Live or accept the risk? In most cases we can learn earlier if things will be show stoppers and more importantly we can automate them. For example; imagine a developer called `Sam` has checked in some poor performing function into an API that spikes it's response time. Let's call this `Sam Code`. This `Sam Code` may not be caught by our Unit Tests but could have very big impact on application usability. Before building code on top this and it becoming more of an issue at the end of a project; we could code and capture metrics around API response time and track these over time and hopefully spot regressions earlier. For example; imagine a developer called `Sam` has checked in some poor performing function into an API that spikes its response time. Let's call this `Sam Code`. This `Sam Code` may not be caught by our Unit Tests but could have very big impact on application usability. Before building code on top this and it becoming more of an issue at the end of a project; we could code and capture metrics around API response time and track these over time and hopefully spot regressions earlier. Another one of the age old questions is "How do we know we're testing enough?". Well the simple answer is you can never do enough testing! But how do we know we are testing the right things? Code coverage metrics can be run on our application while running the tests. They can identify what files are being tested and a line by line of how many times a test executes against a block of code. Reporting these metrics in our pipeline gives a greater handle on the quality of our testing. @@ -218,7 +218,7 @@ 3. Coverage reports are already being generated as part of the tests. We can have Jenkins produce a HTML report showing in detail where our testing is lacking. Open the `todolist-fe` in your favourite editor. 3. Open the `Jenkinsfile` in the root of the project; move to the `stage("node-build"){ ... }` section. In the `post` section add a block for producing a `HTML` report as part of our builds. This is all that is needed for Jenkins to repor the coverage stats. 3. Open the `Jenkinsfile` in the root of the project; move to the `stage("node-build"){ ... }` section. In the `post` section add a block for producing a `HTML` report as part of our builds. This is all that is needed for Jenkins to report the coverage stats. ```groovy // Post can be used both on individual stages and for the entire build. post { @@ -237,7 +237,7 @@ } ``` 3. To get the linting working; we will add a new step to our `stage("node-build"){ }` section to lint the Javascript code. Continuing in the `Jenkinsfile`, After the `npm install`; add a command to run the linting. 3. To get the linting working; we will add a new step to our `stage("node-build"){ }` section to lint the JavaScript code. Continuing in the `Jenkinsfile`, After the `npm install`; add a command to run the linting. ```groovy echo '### Install deps ###' sh 'npm install' @@ -274,9 +274,9 @@ 3. (Optional Step) - Install the Checkstyle plugin; and add `checkstyle pattern: 'eslint-report.xml'` below the `publishHTML` block to add reporting to Jenkins! ### Part 3 - Nightly light performance testing > _In this exercise, we will execute the light performance tasks in our API to collect data about throughtput time in hopes if the API ever has some `Sam` quality code checked in, we will spot it_ > _In this exercise, we will execute the light performance tasks in our API to collect data about throughput time in hopes if the API ever has some `Sam` quality code checked in, we will spot it_ An arbitrary value for the API's to respond in has been chosen. It is set in the `todolist-api/tasks/perf-test.js` file. In this exercise we will get Jenkins to execute the tests and fail based on the score set there! An arbitrary value for the APIs to respond in has been chosen. It is set in the `todolist-api/tasks/perf-test.js` file. In this exercise we will get Jenkins to execute the tests and fail based on the score set there! 4. Create a new Item on Jenkins, `nightly-perf-test` and make it a freestyle job.  @@ -307,7 +307,7 @@ 4. On the Post Build actions section we will plot the data from the perf tests in Jenkins. Add a `Post-build Action > Plot Build Data`. 4. On the new dialog, name the Plot group eg `benchmark-tests` and add `create-api` as the Plot title. Set the `Number of Builds to Include` to a large number like `100`. Set the Data Series file to be `reports/server/perf/create-perf-score.csv` and mark the `Load data from CSV fiel` checkbox. Apply those changes 4. On the new dialog, name the Plot group e.g. `benchmark-tests` and add `create-api` as the Plot title. Set the `Number of Builds to Include` to a large number like `100`. Set the Data Series file to be `reports/server/perf/create-perf-score.csv` and mark the `Load data from CSV field` checkbox. Apply those changes  4. Hit `Add Plot` to add another. Set Plot group to `benchmark-tests` again but this time setting the Plot title to `show-api`. Set the Data Series file to be `reports/server/perf/show-perf-score.csv` and mark the `Load data from CSV` radio button. Save those changes and run the job (Job could take a while to execute!). 6-return-of-the-app-monitoring/README.md
@@ -137,7 +137,7 @@ - Add `Slack` integration to the Pipeline by setting up a WebHook to call the slack endpoint with Build Stats - Add `Twillio` text integration to send you text messages when the build fails. Additional Monitoring - Explore the Application's FEK stack inside OpenShift - Explore the Application's EFK stack inside OpenShift ## Additional Reading > List of links or other reading that might be of use / reference for the exercise 7-the-cluster-awakens/README.md
8-the-last-unicorn-dev/README.md
@@ -10,10 +10,10 @@ _____ ## Learning Outcomes As a learner you will be able to identify what a an amazing Demo Day consists of! - Identify key success factors for a facilitating Demo Day As a learner you will be able to identify what an amazing Demo Day consists of! - Identify key success factors for facilitating a Demo Day - Run Demo Day as part of the class room activities - Identify the success factors and antipatterns in making Labs Engagements work wit our clients - Identify the success factors and antipatterns in making Labs Engagements work with our clients _____
