| exercises/0-rogue-cluster/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/1-the-manual-menace/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/2-attack-of-the-pipelines/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/3-revenge-of-the-automated-testing/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/4-an-enslaved-hope/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/5-non-functionals-strike-back/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/6-return-of-the-app-monitoring/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/7-the-cluster-awakens/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/8-the-last-unicorn-dev/README.md | ●●●●● patch | view | raw | blame | history |
exercises/0-rogue-cluster/README.md
@@ -1,5 +1,5 @@ # Rogue Cluster > This section contains information needed when setting up the cluster for the learners. > This section contains information needed when setting up the cluster for the learners. _____ @@ -8,17 +8,17 @@ </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 - PostgreSQL requires 1Gi of Storage and 512Mi of RAM - PostgreSQL requires 1Gi of Storage and 512Mi of RAM - Redis requires 512Mi of storage - Nexus requires ## Cluster Access ## 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 ## User privileges - Learners will require privileges to run SCC containers ie 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 i.e. GitLab exercises/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.  @@ -8,9 +8,9 @@ This exercise uses Ansible to drive the creation of the cluster content. In particular; we'll use a play book called the `OpenShift Applier`. Once the project namespace have been created; we will add some tools to support CI/CD such as Jenkins, Git and Nexus. These tools will be needed by later lessons to automate the build and deploy of our apps. Again; we will use OpenShift Templates and drive their creation in the cluster using Ansible. To prove things are working, finally we'll delete all our content and re-apply the inventory to re-create our clusters content. #### Why is config-as-code important? #### 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,11 +52,11 @@ 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 2. Burn it all down and re-apply your inventory proving config-as-code works. 2. Burn it all down and re-apply your inventory proving config-as-code works. ## Step by Step Instructions > This is a structured guide with references to exact filenames and explanations. @@ -106,7 +106,7 @@ * `requirements.yml` is a manifest which contains the ansible modules needed to run the playbook * `apply.yml` is a playbook that sets up some variables and runs the OpenShift Applier role. 3. Open the `apply.yml` file in the root of the project. Update the namespace variables by replacing the `<YOUR_NAME>` with your name or initials. Don't use uppercase or special characters. For example; my name is Dónal so I've created: 3. Open the `apply.yml` file in the root of the project. Update the namespace variables by replacing the `<YOUR_NAME>` with your name or initials. Don't use uppercase or special characters. For example; my name is Dónal so I've created: ```yaml hosts: "{{ target }}" vars: @@ -121,11 +121,11 @@ 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. * Create another two params files `params/project-requests-dev` & `params/project-requests-test`. On the terminal run 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 ``` @@ -162,7 +162,7 @@ ansible-galaxy install -r requirements.yml --roles-path=roles ``` 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent as shown below). Accept any insecure connection warning 👍: 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent as shown below). Accept any insecure connection warning 👍: ```bash oc login https://console.lader.rht-labs.com ``` @@ -173,7 +173,7 @@ 3. Once successful you should see an output similar to this (Cow's not included):  3. You can check to see the projects have been created successfully by running 3. You can check to see the projects have been created successfully by running ```bash oc projects ``` @@ -188,7 +188,7 @@ ``` The template contains all the things needed to setup a persistent nexus server, exposing a service and route while also creating the persistent volume needed. Have a read through the template; at the bottom you'll see a collection of parameters we will pass to the template. 4. Add some parameters for running the template by creating a new file in the `params` directory. 4. Add some parameters for running the template by creating a new file in the `params` directory. ```bash touch params/nexus ``` @@ -227,7 +227,7 @@ ### Part 3 - GitLab #### 3a - GitLab install #### 3a - GitLab install <p class="tip"> NOTE - This section may already have been completed for you, please check with your tutor. If this is the case, skip to section 3b "Commit CI/CD" below to add your code to GitLab. </p> @@ -235,7 +235,7 @@ 4. Now let's do the same thing for GitLab to get it up and running. Checkout the template and params provided by running ```bash git checkout exercise1/git-nexus templates/gitlab.yml params/gitlab ``` ``` Explore the template; it contains the PVC, buildConfig and services. The DeploymentConfig is made up of these apps - Redis (3.2.3) - PostgreSQL (9.4) @@ -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 @@ -412,21 +412,21 @@ * `build-failure-analyzer.xml` is config for the plugin to read the logs and look for key items based on a Regex. More on this in later lessons. * `init.groovy` contains a collection of settings jenkins configures itself with when launching 5. Let's add a plugin for Jenkins to be started with, [green-balls](https://plugins.jenkins.io/greenballs). This simply changes the default `SUCCESS` status of Jenkins from Blue to Green. Append the `jenkins-s2i/plugins.txt` file with 5. Let's add a plugin for Jenkins to be started with, [green-balls](https://plugins.jenkins.io/greenballs). This simply changes the default `SUCCESS` status of Jenkins from Blue to Green. Append the `jenkins-s2i/plugins.txt` file with ```txt greenballs:1.15 ``` ```  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` @@ -434,7 +434,7 @@ git checkout exercise1/jenkins-s2i params/jenkins-s2i templates/jenkins-s2i.yml ``` 5. Open `params/jenkins-s2i` and add the following content; replacing variables as appropriate. 5. Open `params/jenkins-s2i` and add the following content; replacing variables as appropriate. ``` SOURCE_REPOSITORY_URL=<GIT_URL> NAME=jenkins @@ -443,7 +443,7 @@ SOURCE_REPOSITORY_USERNAME=<YOUR_LDAP_USERNAME> SOURCE_REPOSITORY_PASSWORD=<YOUR_LDAP_PASSWORD> ``` where where * `<GIT_URL>` is the full path clone path of the repo where this project is stored (including the https && .git) * `<YOUR_NAME>` is the prefix for your `-ci-cd` project. * Explore some of the other parameters in `templates/jenkins-s2i.yml` @@ -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,9 +498,9 @@ 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 ### 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._ 6. Log in to Jenkins and hit `New Item` . @@ -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 exercises/2-attack-of-the-pipelines/README.md
@@ -7,7 +7,7 @@ ## Exercise Intro This lesson is focused on creating a pipeline for our application. What is a pipeline? A pipeline is a series of steps or stages that takes our code from source to a deployed application. There can be many stages to a pipeline but a simple flow is to run a `build > bake > deploy`. Usually the first stage is trigger by something like a git commit. There could be many steps in each of these stages; such as compiling code, running tests and linting. All of these are done to try and drive up code quality and give more assurance that what is deployed is behaving as expected. In the exercise we will create Jenkins pipeline by configuring it through the UI, this will create an un-gated pathway to production First we will explore the sample application and get it running locally. The sample app is a `todolist` app - the `Hello World` app of the modern day. First we will explore the sample application and get it running locally. The sample app is a `todolist` app - the `Hello World` app of the modern day. #### Why create pipelines * Assurance - drive up code quality and remove the need for dedicated deployment / release management teams @@ -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 @@ -111,7 +111,7 @@ node -v npm -v ``` <p class="tip" > <p class="tip" > NOTE - If you are missing these dependencies; install them with ease using the [Node Version Manager](https://github.com/creationix/nvm) </p>  @@ -176,7 +176,7 @@ * `./src/store` is the `vuex` files for managing application state and backend connectivity * `./src/views` is the view containers; which are responsible for loading components and managing their interactions. * the `./src/router.js` controls routing logic. In our case the app only has one real endpoint. * `./src/scss` contains custom SCSS used in the application. * `./src/scss` contains custom SCSS used in the application. * `./*.js` is mostly config files for running and managing the app and the tests 2. To prepare Nexus to host the binaries created by the frontend and backend builds we need to run a prepare-nexus script. Before we do this we need to export some variables and change `<YOUR_NAME>` accordingly in the below commands. @@ -260,10 +260,10 @@ where the following are the important things: * `./server` is the main collection of files needed by the app. The entrypoint is the `app.js` * `./node_modules` is where the dependencies are stored * `./server/api` is where the api's controller, data model & unit test are stored. * `./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 @@ -284,7 +284,7 @@ }, ``` 2. To run the application; start a new instance of the MongoDB by running the following. This will pull a mongodb image from Dockerhub and then start it for our API to connect to. 2. To run the application; start a new instance of the MongoDB by running the following. This will pull a mongodb image from Dockerhub and then start it for our API to connect to. ```bash npm run mongo ``` @@ -320,10 +320,10 @@ 2. Now let's check out `todolist-fe` app by reloading the browser. We should now see our dummy front end data is replaced by the backend seed data. Adding new todos will add them in the backend, these will persist when the page is refreshed.  ### Part 2 - Add configs to cluster ### 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 @@ -344,19 +344,19 @@ └── todolist-fe-deploy.yml ``` with the following * the `apply.yml` file is the entrypoint. * the `apply.yml` file is the entrypoint. * the `inventory` contains the objects to populate the cluster with. * the `params` contains the variables we'll apply to the `templates` * the `templates` required by the app. These include the Build, Deploy configs as well as the services, health checks, and other app definitions. 4. There are a few updates to these manifests we need to make before applying the cluster content. In the `apply.yml` update the namespace `<YOUR_NAME>` variables accordingly. 4. There are a few updates to these manifests we need to make before applying the cluster content. In the `apply.yml` update the namespace `<YOUR_NAME>` variables accordingly. ```yaml ci_cd_namespace: donal-ci-cd dev_namespace: donal-dev test_namespace: donal-test ``` 4. In the `params` folder update the `dev` and `test` files with the correct `<YOUR_NAME>` as you've done above. Example for the `dev` file: 4. In the `params` folder update the `dev` and `test` files with the correct `<YOUR_NAME>` as you've done above. Example for the `dev` file: ```bash PIPELINES_NAMESPACE=donal-ci-cd NAME=todolist-fe @@ -428,7 +428,7 @@ 4. Check `<YOUR_NAME>-dev` to see the deployment configs are in place  ### Part 3 - Build > Bake > Deploy ### Part 3 - Build > Bake > Deploy > _In this exercise; we take what we have working locally and get it working in OpenShift_ This exercise will involve creating three stages (or items) in our pipeline, each of these is detailed below at a very high level. Move on to the next step to begin implementation. @@ -457,7 +457,7 @@ 5. Name this job `dev-todolist-fe-build` and select `Freestyle Job`. All our jobs will take the form of `<ENV>-<APP_NAME>-<JOB_PURPOSE>`.  5. The page that loads is the Job Configuration page and it can be returned to at anytime from Jenkins. Let's start configuring our job. To conserve space; we will make sure Jenkins only keeps the last builds artifacts. Tick the `Discard old builds` checkbox, then `Advanced` and set `Max # of builds to keep with artifacts` to 1 as indicated below 5. The page that loads is the Job Configuration page and it can be returned to at anytime from Jenkins. Let's start configuring our job. To conserve space; we will make sure Jenkins only keeps the last builds artifacts. Tick the `Discard old builds` checkbox, then `Advanced` and set `Max # of builds to keep with artifacts` to 1 as indicated below  5. Our NodeJS build needs to be run on the `jenkins-slave-npm` we bought in in the previous chapter. Specify this in the box labelled `Restrict where this project can be run`  @@ -480,7 +480,7 @@ 5. On the Post-build Actions; Add another post-build action from the dropdown called `Git Publisher`. This is useful for tying the git check-in to the feature in your tracking tool to the built product. * Tick the box `Push Only If Build Succeeds` * Add the Tag to push of * Add the Tag to push of ```bash ${JOB_NAME}.${BUILD_NUMBER} ``` @@ -492,10 +492,10 @@ * Check `Create New Tag` and set `Target remote name` to `origin`  5. Finally; add the trigger for the next job in the pipeline. This is to trigger the bake job with the current build tag. Add another post-build action from the dropdown called `Trigger parameterized build on other projects`. * Set the project to build to be `dev-todolist-fe-bake` * Set the condition to be `Stable or unstable but not failed`. * Click Add Parameters dropdown and select Predefined parameters. 5. Finally; add the trigger for the next job in the pipeline. This is to trigger the bake job with the current build tag. Add another post-build action from the dropdown called `Trigger parameterized build on other projects`. * Set the project to build to be `dev-todolist-fe-bake` * Set the condition to be `Stable or unstable but not failed`. * Click Add Parameters dropdown and select Predefined parameters. * In the box, insert our BUILD_TAG as follows ```bash BUILD_TAG=${JOB_NAME}.${BUILD_NUMBER} @@ -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> @@ -590,7 +590,7 @@ 5. Update `<YOUR_NAME>` accordingly with the route where the Todo List API will live when it is deployed. The correct full URL can also be found on the OpenShift Console; if you copy it from there remember to append `/api/todos` to the URL. For example:  5. Repeat this for `src/config/test.js` file. If you copy the URL from the previous step; change `dev` to `test`. 5. Repeat this for `src/config/test.js` file. If you copy the URL from the previous step; change `dev` to `test`. For example: 
@@ -15,13 +15,13 @@ The TDD cycle can be illustrated with the following diagram;  ### The TDD Cycle ### The TDD Cycle 1. `Write a test` - In TDD a new feature begins by writing a test. Write a test that clearly defines a function or one that provides an improvement to an existing function. It's important the developer clearly understands the features specification and requirements, or the feature could be wrong from the get-go. In TDD a new feature begins by writing a test. Write a test that clearly defines a function or one that provides an improvement to an existing function. It's important the developer clearly understands the features specification and requirements, or the feature could be wrong from the get-go. 2. `Test Fails` - When a test is first implemented it is expected to fail. This failure validates the test is working correctly as the feature is yet to be implemented. When a test is first implemented it is expected to fail. This failure validates the test is working correctly as the feature is yet to be implemented. 3. `Write code to make test pass` - This step involves implementing the feature to pass the failed test. Code written at this stage may be inelegant and still pass the test, however this is acceptable as TDD is a recursive cycle which includes code refactoring. @@ -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. @@ -60,7 +60,7 @@ 1. [Vue Test Utils](https://vue-test-utils.vuejs.org/en/) - Vue Test Utils is the official unit testing utility library for Vue.js. 1. [Nightwatch.js](http://nightwatchjs.org/) - Nightwatch.js is an easy to use Node.js based End-to-End (E2E) testing solution for browser based apps and websites. It uses the powerful W3C WebDriver API to perform commands and assertions on DOM elements. 1. [Mocha](https://mochajs.org/) - Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub. 1. [Sinon](http://sinonjs.org/) - Standalone test spies, stubs and mocks for JavaScript. 1. [Sinon](http://sinonjs.org/) - Standalone test spies, stubs and mocks for JavaScript. Works with any unit testing framework. ## Big Picture @@ -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 @@ -101,7 +101,7 @@ ```bash npm run test ``` <p class="tip" > <p class="tip" > `test` is an alias used that runs `vue-cli-service test` from the scripts object in `package.json` </p>  @@ -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.  @@ -151,7 +151,7 @@ git push ``` 2. Rerun the `dev-todolist-fe-build` job. It should have failed and not run any other jobs. 2. Rerun the `dev-todolist-fe-build` job. It should have failed and not run any other jobs.  2. You can examine the test results on the jobs home page. Drill down into the tests to see which failed and other useful stats @@ -252,7 +252,7 @@ - `res.body.should.be.instanceof(Array);` is the actual test call - `done();` tells the test runner that `mocha` has finished execution. This is needed as the http calls are asynchronous. 3. With this knowledge; let's implement our test for the `important` flag. We expect the front end to introduce a new property on each `todo` that gets passed to the backend called `important`. The API will need to handle this new property and pass it into the mongodb. Let's begin implementing this functionality by writing our test case. Navigate to the `PUT /api/todos` section of the `server/api/todo/todo.spec.js` test file (which should be at the bottom) 3. With this knowledge; let's implement our test for the `important` flag. We expect the front end to introduce a new property on each `todo` that gets passed to the backend called `important`. The API will need to handle this new property and pass it into the mongodb. Let's begin implementing this functionality by writing our test case. Navigate to the `PUT /api/todos` section of the `server/api/todo/todo.spec.js` test file (which should be at the bottom)  3. Before writing our test; let's first make sure all the existing tests are passing. @@ -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. @@ -340,11 +340,11 @@ ``` #### 2b - Create todolist-fe tests > Using [Jest](https://facebook.github.io/jest/) as our test runner and the `vue-test-utils` library for managing our vue components; we will now write some tests for front end functionality to persist our important-flag. The changes required to the front end are quite large but we will use TDD to create our test first, then implement the functionality. > Using [Jest](https://facebook.github.io/jest/) as our test runner and the `vue-test-utils` library for managing our vue components; we will now write some tests for front end functionality to persist our important-flag. The changes required to the front end are quite large but we will use TDD to create our test first, then implement the functionality. Our TodoList App uses `vuex` to manage the state of the apps' todos and `axios` HTTP library to connect to the backend. `Vuex` is an opinionated framework for managing application state and has some key design features you will need to know to continue with the exercise. Our TodoList App uses `vuex` to manage the state of the apps' todos and `axios` HTTP library to connect to the backend. `Vuex` is an opinionated framework for managing application state and has some key design features you will need to know to continue with the exercise. In `vuex` the application state is managed by a `store`. The `store` houses all the todos we have retrieved from the backend as well as the `getter` methods for our array of `todos`. In order to make changes to the store, we could call the store directly and update each todo item but as earlier said; vuex is an opinionated module with it's own way of updating the store. It is bad practice to call the store directly. In `vuex` the application state is managed by a `store`. The `store` houses all the todos we have retrieved from the backend as well as the `getter` methods for our array of `todos`. In order to make changes to the store, we could call the store directly and update each todo item but as earlier said; vuex is an opinionated module with it's own way of updating the store. It is bad practice to call the store directly. There are two parts of the lifecycle to updating the store, the `actions` & `mutations`. When the user clicks a todo to mark it as complete; the `actions` are called. An action could involve a call to the backend or some pre-processing of the data. Once this is done, the change is committed to the store by calling the `mutation` function. A store should only ever be manipulated through a mutation function. Calling the mutation will then update the todo object in the apps local store for rendering in the view. @@ -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 ``` @@ -413,9 +413,9 @@ }); ``` 3. Finally, we want to make the flag clickable and for it to call a function to update the state. The final test in the `TodoItem.spec.js` we want to create should simulate this behaviour. Implement the `it("call makImportant when clicked", () ` test by first simulating the click of our important-flag and asserting the function `markImportant()` to write is executed. 3. Finally, we want to make the flag clickable and for it to call a function to update the state. The final test in the `TodoItem.spec.js` we want to create should simulate this behaviour. Implement the `it("call markImportant when clicked", () ` test by first simulating the click of our important-flag and asserting the function `markImportant()` to write is executed. ```javascript it("call makImportant when clicked", () => { it("call markImportant when clicked", () => { const wrapper = mount(TodoItem, { methods, propsData: { todoItem: importantTodo } @@ -457,7 +457,7 @@ }, ``` 3. Let's connect the click button in the DOM to the Javascript function we've just created. In the template, add a click handler to the md-button to call the function `markImportant()` by adding ` @click="markImportant()"` to the `<md-button> tag 3. Let's connect the click button in the DOM to the Javascript function we've just created. In the template, add a click handler to the md-button to call the function `markImportant()` by adding ` @click="markImportant()"` to the `<md-button> tag ```html <!-- TODO - SVG for use in Exercise3 --> <md-button class="important-flag" @click="markImportant()"> @@ -469,7 +469,7 @@  3. The previously failing tests should have started to pass now. With this work done, let's commit our code. On the terminal, run 3. The previously failing tests should have started to pass now. With this work done, let's commit our code. On the terminal, run ```bash git add . ``` @@ -587,4 +587,4 @@ - [Intro](https://docs.google.com/presentation/d/18W0GoBTwRGpgbOyHf2ZnL_OIWU_DvsoR14H0_t5jisA) - [Wrap-up](https://docs.google.com/presentation/d/1uIYHC57POSaVD6XNZGhdetABiSnlP1TztYTgglMP-DA) - [All Material](https://drive.google.com/drive/folders/1xVaQukmwwmyJSDN0zOkghZX7yb-0freT) - [All Material](https://drive.google.com/drive/folders/1xVaQukmwwmyJSDN0zOkghZX7yb-0freT) exercises/4-an-enslaved-hope/README.md
@@ -1,20 +1,20 @@ # An Enslaved Hope > In this exercise we'll break free from the chains of point'n'click Jenkins by introducing pipeline as code in the form of `Jenkinsfile`. Following this we will introduce some new Jenkins slaves that will be used in later exercises. > In this exercise we'll break free from the chains of point'n'click Jenkins by introducing pipeline as code in the form of `Jenkinsfile`. Following this we will introduce some new Jenkins slaves that will be used in later exercises.  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 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 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 _____ ## Learning Outcomes As a learner you will be able to - Use a Jenkinsfile to create a declarative pipeline to build, bake and deploy the Todolist App - Identify the differences between scripted, declarative and DSL pipelines - Use a Jenkinsfile to create a declarative pipeline to build, bake and deploy the Todolist App - Identify the differences between scripted, declarative and DSL pipelines - Create Jenkins slave nodes for use in builds in future exercises ## Tools and Frameworks @@ -39,7 +39,7 @@ 2. Create two new Jenkins slaves for the `OWASP ZAP` scanner and the `Arachni` WebCrawler ## Step by Step Instructions > This is a fairly structured guide with references to exact filenames and sections of text to be added. > This is a fairly structured guide with references to exact filenames and sections of text to be added. ### Part 1 - The Jenkinsfile > _In this exercise we'll replace the Pipeline we created in Exercise 2 with a Jenkinsfile approach_ @@ -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,10 +100,10 @@ 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. 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.  2. The pipeline file is setup to only run `bake` & `deploy` stages when on `master` or `develop` branch. This is to provide us with very fast feedback for team members working on feature or bug fix branches. Each time someone commits or creates a new branch a basic build with testing occurs to give very rapid feedback to the team. Let's now update our `master` and `develop` branches to include the Jenkinsfile and delete the feature branch. @@ -149,10 +149,10 @@ git checkout feature/jenkinsfile ``` 2. Open up your `todolist-fe` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. Update all `<YOUR_NAME>` and `<GIT_USERNAME>` as you did before, including in the prepare environment steps. Check the `GITLAB_DOMAIN` is set too. 2. Open up your `todolist-fe` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. Update all `<YOUR_NAME>` and `<GIT_USERNAME>` as you did before, including in the prepare environment steps. Check the `GITLAB_DOMAIN` is set too.  2. Commit your changes to your feature branch as you did previously. 2. Commit your changes to your feature branch as you did previously. ```bash git add Jenkinsfile ``` @@ -193,7 +193,7 @@ 2. On Jenkins; create a new `Multibranch Pipeline` job called `todolist-fe`. 2. Add the `todolist-fe` git repository and set the credentials for git accordingly. 2. Add the `todolist-fe` git repository and set the credentials for git accordingly. 2. Set the trigger to scan every minute as done previously. Save the configuration and we should see the collection of Jobs as shown below.  @@ -224,7 +224,7 @@ ```  2. Use the OpenShift Applier to create the cluster content 2. Use the OpenShift Applier to create the cluster content ```bash cd .openshift-applier ``` @@ -267,7 +267,7 @@ NAME=todolist-api ``` 2. Use the OpenShift Applier to create the cluster content 2. Use the OpenShift Applier to create the cluster content ```bash cd todolist-api/.openshift-applier ``` @@ -322,15 +322,15 @@ -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 > _Arachni is a feature-full, modular, high-performance Ruby framework aimed towards helping penetration testers and administrators evaluate the security of web applications._ 3. On your terminal; checkout the params and Docker file. The Dockerfile for the `Arachni` scanner is included here and we will point the build to it. 3. On your terminal; checkout the params and Docker file. The Dockerfile for the `Arachni` scanner is included here and we will point the build to it. ```bash git checkout exercise4/zap-and-arachni params/jenkins-slave-arachni docker/jenkins-slave-arachni git checkout exercise4/zap-and-arachni params/jenkins-slave-arachni docker/jenkins-slave-arachni ``` 3. Create an object in `inventory/host_vars/ci-cd-tooling.yml` called `jenkins-slave-arachni` with the following content: @@ -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`.  _____ @@ -382,8 +382,8 @@ - Add the multi-branch configuration to the S2I to have Jenkins come alive with the `todolist-api` and `-fe` configuration cooked into it for future uses. 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 - 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 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. @@ -395,4 +395,4 @@ - [Intro](https://docs.google.com/presentation/d/1B3Fv4g66zZ8ZkqBq9TYmImJhUDvMecXCt4q3DXGWhjc/) - [Wrap-up](https://docs.google.com/presentation/d/1EOk6y798Xh1hsaQlxRuqyr23FIIf7sNY4any_yXIL7A/) - [All Material](https://drive.google.com/drive/folders/1oCjpl33Db7aPocmpu3NNF0B9czRvFq3m) - [All Material](https://drive.google.com/drive/folders/1oCjpl33Db7aPocmpu3NNF0B9czRvFq3m) exercises/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. @@ -63,7 +63,7 @@ ## Step by Step Instructions > This is a well structured guide with references to exact filenames and indications as to what should be done. ### Part 1 - Add Security scanning to the pipeline ### Part 1 - Add Security scanning to the pipeline > _In this exercise the first of our non-functional testing is explored in the form of some security scanning. We will add the scans to our Jenkinsfile and have them run as new stages_ 2. Open the `todolist-fe` application's `Jenkinsfile` in your favourite editor. The file is stored in the root of the project. @@ -71,7 +71,7 @@ 2. The file is layed out with a collection of stages that correspond to each part of our build as seen below. We will create a new stage to execute in parallel.  2. Create a new Parallel Stage called `security scanning` underneath the `stage("e2e test") { }` section as shown below. The contents of the `e2e test` have been removed for simplicity. 2. Create a new Parallel Stage called `security scanning` underneath the `stage("e2e test") { }` section as shown below. The contents of the `e2e test` have been removed for simplicity. ```groovy stage("e2e test") { // ... stuff in here .... @@ -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' @@ -259,24 +259,24 @@ 3. When the build has completed; fix the linting errors if there are any and commit your changes. Look in Jenkins log for what the issue might be....  3. To view the coverage graph; go to the job's build page and open the `Code Coverage` report from the nav bar on the side. 3. To view the coverage graph; go to the job's build page and open the `Code Coverage` report from the nav bar on the side. <p class="tip"> NOTE - Sometimes this won't display on the `yourjenkins.com/job/todolist-fe/job/branch/` sidebar, click on an individual build in the build history and it should appear on the side navbar. </p>  3. Open the report to drill down into detail of where testing coverage could be improved! 3. Open the report to drill down into detail of where testing coverage could be improved!  <p class="tip"> NOTE - a good practice for teams is to try and increase the code coverage metrics over the life of a project. Teams will often start low and use practices such as retrospective to increase the quality at specific times. NOTE - a good practice for teams is to try and increase the code coverage metrics over the life of a project. Teams will often start low and use practices such as retrospective to increase the quality at specific times. </p> 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!). @@ -334,4 +334,4 @@ - [Intro](https://docs.google.com/presentation/d/1YQ0hUV3o7DW8O40SiI-BQZXCOSVeQGjo2iTxCL2GZfk/) - [Wrap-up](https://docs.google.com/presentation/d/102hRHDlC9PUIsMs3m1fZy8QUaB5UKzBlhBPdehRWw38/) - [All Material](https://drive.google.com/drive/folders/1seT0V3ABHNonvtFvORNt836NgSeYPuWW) - [All Material](https://drive.google.com/drive/folders/1seT0V3ABHNonvtFvORNt836NgSeYPuWW) exercises/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 exercises/7-the-cluster-awakens/README.md
@@ -1,6 +1,6 @@ # The Cluster Awakens > In this exercise; we will monitor the core of the OpenShift Cluster. Watch for spikes in memory usage, harddisk space and other cluster stats. > In this exercise; we will monitor the core of the OpenShift Cluster. Watch for spikes in memory usage, hard disk space and other cluster stats.  @@ -8,7 +8,7 @@ ## Learning Outcomes As a learner you will be able to - View vital stats about the clusters health using Prometheus queries - View vital stats about the clusters health using Prometheus queries - Visualise the data on Grafana dashboards - Overlay log messages to the Grafana dashboards creating a very short feedback loop for Ops and Dev teams. @@ -43,4 +43,4 @@ - [Intro](https://docs.google.com/presentation/d/179Bz9GzHIcDxwb4RxxlQUESfqES4hArU1puGUjkAOoI/) - [Wrap-up](https://docs.google.com/presentation/d/1n6f_A3i5019lZYmCBNhl9O-S3xxjpHDT5I7ZoCqYyHo/) - [All Material](https://drive.google.com/drive/folders/13YIiKuzBmr9mGzg4bsEns5yVWx_Zc8Hs) - [All Material](https://drive.google.com/drive/folders/13YIiKuzBmr9mGzg4bsEns5yVWx_Zc8Hs) exercises/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 _____ @@ -21,4 +21,4 @@ - [Intro](https://docs.google.com/presentation/d/1XW_k9LYEcA4yk46GvN5yWih545gKUNeQW4-5GF9jYDg/) - [Wrap-up](https://docs.google.com/presentation/d/1veO6Q7yG1Kmy-3GfjZnGlsQ7NOXTyRBiYJWMA8y3CEE/) - [All Material](https://drive.google.com/drive/folders/1TmpX5uCwzfsZfFHNlXXZZ4r6wiMDDO4i) - [All Material](https://drive.google.com/drive/folders/1TmpX5uCwzfsZfFHNlXXZZ4r6wiMDDO4i)
