exercises/1-the-manual-menace/README.md
@@ -178,7 +178,7 @@ ### Part 2 - Nexus and GitLab > _Now that we have our Projects setup; we can start to populate them with Apps to be used in our dev lifecycle_ #### Part 2a - Nexus #### 2a - Nexus 4. In the `enablement-ci-cd` repo, checkout the templates for Nexus by running ```bash $ git checkout exercise1/git-nexus templates/nexus.yml @@ -222,7 +222,7 @@ 4. Once successful; login to the cluster through the browser (using cluster URL) and navigate to the `<YOUR_NAME>-ci-cd`. You should see Nexus up and running. You can login with default credentials (admin / admin123)  #### Part 2b - GitLab #### 2b - GitLab <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 6 to add your code to GitLab. </p> exercises/2-attack-of-the-pipelines/README.md
@@ -77,7 +77,7 @@ ### Part 1 - Explore the Todo List App > _In this part of the exercise we will explore the sample application, become familiar with it locally before building and deploying in OCP Land_ #### Part 1a Todolist-fe #### 1a Todolist-fe 2. Git clone the `todolist-fe` project to somewhere sensible and checkout the `develop` branch. ```bash @@ -185,7 +185,7 @@ NOTE - This step in a residency would be automated by a more complex nexus deployment in the ci-cd project </p> #### Part 1b Todolist-api #### 1b Todolist-api 2. Now let's move on to the `todolist-api` and wire them together. As with the `todolist-fe` we need to clone the repo and add it to our GitLab in the cluster. ```bash @@ -475,7 +475,7 @@ 4. Verify the deployment * We will now go through these steps in detail. #### Part 4a - Build #### 4a - Build 5. With the BuildConfig and DeployConfig in place for both our apps (`*-fe` & `*-api`) from previous steps; Log into Jenkins and create a `New Item`. This is just jenkins speak for a new job configuration.  @@ -531,7 +531,7 @@ 5. Hit `save` which will take you to the job overview page - and that's it; our *build* phase is complete! #### Part 4b - Bake #### 4b - Bake 5. Next we will setup our *bake* phase; which is a little simpler. Go to Jenkins home and create another Freestyle Job (as before) called `dev-todolist-fe-bake`. @@ -572,7 +572,7 @@ 5. Hit save! That's our *bake* phase done! Finally; on to our *deploy* #### Part 4c - Deploy #### 4c - Deploy 5. Next we will setup our *deploy* phase. This job is very similar in setup to the *bake* phase so this time go to Jenkins home and create `dev-todolist-fe-deploy` Job but scroll to the bottom and Copy from `dev-todolist-fe-bake`.  @@ -601,7 +601,7 @@ 5. Finally; delete the Post Build Action to trigger another job (by hitting the red X). Save the configuration. We're almost ready to run the pipeline! #### Part 4d - Pipeline #### 4d - Pipeline 5. With our Jenkins setup in place; now move to our `todolist-fe` app's source code. We have to add our configuration to the frontend to tell it where the API layer will be hosted. Open the source in your favourite editor and navigate to `src/config/dev.js`. Update `<YOUR_NAME>` accordingly with the route where the Todo List API will live when it is deployed, update the `somedomain` to the clusters domain. For example:  exercises/3-revenge-of-the-automated-testing/README.md
@@ -91,7 +91,7 @@ ### Part 1 - Tests in our Pipeline > _In this part we will get familiar with the layout of our tests. We will also improve the pipeline created already by adding some unit tests for the frontend & backend along with some end to end tests (e2e) to validate the full solution_ #### Part 1a - FE Unit tests #### 1a - FE Unit tests > In this exercise we will execute our test for the frontend locally. Once verified we will add them to Jenkins. 2. Before linking our automated testing to the pipeline we'll first ensure the tests run locally. Change to the `todolist-fe` directory and run `test`. @@ -148,7 +148,7 @@ 2. Undo the changes you made to the `ListOfTodos.spec.js` file, commit your code and rerun the build. This should trigger a full `build --> bake --> deploy` of `todolist-fe`. #### Part 1b - BE Unit tests #### 1b - BE Unit tests > In this exercise we will execute our test for the backend locally. Once verified we will add them to Jenkins and add a mongodb to Jenkins for running tests there. 2. We're now going to do the same for the api. However, in order to run our API tests in CI; we need there to be a MongoDB available for testing. In our `enablement-ci-cd` repo; checkout the mongo branch as shown below to bring in the template and params. The mongodb template we're using is the same as the one for our `todolist-fe` created in previous lab. @@ -208,7 +208,7 @@ NOTE - Don't forget to undo the changes that you made to your tests! </p> #### Part 1c - End to End tests (e2e) #### 1c - End to End tests (e2e) > _Unit tests are a great way to get immediate feedback as part of testing an application. End to end tests that drive user behaviour are another amazing way to ensure an application is behaving as expected._ In this exercise we will add a new stage to our pipeline called `dev-todolist-fe-e2e` that will run after the deploy has been completed. End to end tests will use Nightwatchjs to orchestrate a selenium webdriver instance that controls the web browser; in this case Chrome! @@ -265,7 +265,7 @@ - [ ] should display existing todos that are not marked important - [ ] should display existing todos that are marked important with an red flag #### Part 2a - Create todolist-api tests #### 2a - Create todolist-api tests > Using [Mocha](https://mochajs.org/) as our test runner; we will now write some tests for backend functionality to persist our important-flag. The changes required to the backend are minimal but we will use TDD to create our test first, then implement the functionality. 3. Create a new branch in your `todolist-api` app for our feature and push it to the remote @@ -494,6 +494,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 ```html <!-- TODO - SVG for use in Lab3 --> <md-button class="important-flag" @click="markImportant()"> @@ -512,7 +513,9 @@ $ git push ``` 3. If we try to use our important flag, we should see it's still not behaving as expected; this is because we're not updating the state of the app in response to the click event. We need to implement the `actions` and `mutations` for our feature. Let's start with the tests. Open the `tests/unit/javascript/actions.spec.js` and navigate to the bottom of the file. Our action should should commit the `MARK_TODO_IMPORTANT` to the mutations. Scroll to the end of the test file and implement the skeleton test by adding `expect(commit.firstCall.args[0]).toBe("MARK_TODO_IMPORTANT");` as the assertion. 3. Open our local todolist app (http://localhost:8080/#/todo). If we try to use our important flag, we should see it's still not behaving as expected; this is because we're not updating the state of the app in response to the click event. 3. We need to implement the `actions` and `mutations` for our feature. Let's start with the tests. Open the `tests/unit/javascript/actions.spec.js` and navigate to the bottom of the file. Our action should should commit the `MARK_TODO_IMPORTANT` to the mutations. Scroll to the end of the test file and implement the skeleton test by adding `expect(commit.firstCall.args[0]).toBe("MARK_TODO_IMPORTANT");` as the assertion. ```javascript it("should call MARK_TODO_IMPORTANT", done => { const commit = sinon.spy(); @@ -562,6 +565,7 @@ state.todos[index].important = !state.todos[index].important; } ```  3. All our tests should now be passing. On the watch tab where they are running, hit `a` to re-run all tests and update any snapshots with `u` if needed. @@ -572,7 +576,7 @@ $ git push ``` 3. Before running a build in Jenkins, let's add our tests and code to the develop branch 3. Before running a build in Jenkins, let's add our tests and code to the develop branch. Ask your neighbour to review your code changes and if they approve; merge them to Develop! (If you're feeling adventurous - raise a PR through GitLab and have someone on your desk peer review it!) <p class="tip"> NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch! </p> @@ -582,9 +586,10 @@ $ git push --all ``` 3. Run a build in Jenkins. We should see the test trend increase as we've added more tests. Validate the flag is working as expected. 3. Run a build in Jenkins. If all things were successful; our application should be deployed as expected! Validate the flag is working as expected.  #### Part 2c - Create todolist e2e tests #### 2c - Create todolist e2e tests 3. TODO !! @@ -594,7 +599,6 @@ > _Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution and are provided for additional scope._ * Edit the `dev-todolist-fe-e2e` job so it takes a parameter of the `BUILD_TAG` and only checks out this tag when running the e2e * Add Config maps to inject DB creds to the app * Create a blue/green deploy based on the success of running e2e tests against either blue or green and flopping load over to new endpoint when successful. Advanced exercises/4-an-enslaved-hope/README.md
@@ -59,7 +59,7 @@ * `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. 2. The Jenkinsfile is mostly complete to do all the testing etc that was done in previous labs. Some minor changes will be needed to orchestrate namespaces. Find and replace all instances of `<YOUR_NAME>` in the Jenkinsfile and update the `GITLAB_DOMAIN` accordingly. 2. The Jenkinsfile is mostly complete to do all the testing etc that was done in previous labs. 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 environment { // GLobal Vars @@ -71,8 +71,8 @@ GIT_SSL_NO_VERIFY = true GIT_CREDENTIALS = credentials('jenkins-git-creds') GITLAB_DOMAIN = "gitlab-<YOUR_NAME>-ci-cd.apps.somedomain.com" GITLAB_PROJECT = "<YOUR_NAME>" GITLAB_DOMAIN = "gitlab.apps.lader.rht-labs.com" GITLAB_PROJECT = "<GIT_USERNAME>" } ``` @@ -91,7 +91,7 @@ 2. On the job's configure page; set the Branch Sources to `git`  2. Fill in the Git settings with your `todolist-api` project url and setting the credentials 2. Fill in the Git settings with your `todolist-api` GitLab url and set the credentials as you've done before.  2. Set the `Scan Multibranch Pipeline Triggers` to be periodical and the internal to 1 minute. This will poll the gitlab instance for new branches or change sets to build. @@ -100,10 +100,13 @@ 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/jenkisifle` 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 branches to include the Jenkinsfile and delete the feature branch. 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. ```bash $ git checkout develop $ git merge feature/jenkinsfile # you may get merge conflicts at this point $ git add . $ git commit -m "Jenkinsfile updates" $ git checkout master $ git merge develop $ git push -u origin --all @@ -124,7 +127,8 @@ $ 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 `GITLAB_DOMAIN` references accordingly. 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. ```bash @@ -135,11 +139,16 @@ 2. This time update your master and develop branches before creating config in Jenkins ``` git checkout develop git merge feature/jenkinsfile git checkout master git merge develop git push -u origin --all $ git checkout develop $ git merge feature/jenkinsfile # you may get merge conflicts at this point $ git add . $ git commit -m "Jenkinsfile updates" $ git checkout master $ git merge develop # this is to delete the branch from the remote $ git push origin :feature/jenkinsfile $ git push -u origin --all ``` 2. On Jenkins; create a new `Multibranch Pipeline` job called `todolist-fe`. @@ -150,7 +159,7 @@  2. Run the jobs and validate the app is working as expected in the `test` environment!  ### Part 2 - OCP Pipeline > _This exercise adds a new BuildConfig to our cluster for the todolist-apps to run their pipelines in OpenShift using the OpenShift Jenkins Sync Plugin. We will use the OpenShift Applier to create the content in the cluster_ @@ -159,7 +168,7 @@ 2. Open the `params/ocp-pipeline` file and update `PIPELINE_SOURCE_REPOSITORY_URL` with the git url of your project (Don't forget to add the `.git` at the end). For example: ``` PIPELINE_SOURCE_REPOSITORY_URL=https://gitlab-<YOUR_NAME>-ci-cd.apps.somedomain.com/<YOUR_NAME>/todolist-fe.git PIPELINE_SOURCE_REPOSITORY_URL=https://gitlab.apps.lader.rht-labs.com/<GIT_USERNAME>/todolist-fe.git PIPELINE_SOURCE_REPOSITORY_REF=develop NAME=todolist-fe ``` @@ -182,6 +191,13 @@ -e "filter_tags=pipeline" ``` 2. With these changes in place, commit your changes to GitLab ```bash $ git add . $ git commit -m "ADD - ocp pipeline in git repo" $ git push ``` 2. Login to your OpenShift Cluster and go to the `<YOUR_NAME>-ci-cd` namespace. On the side menu; hit Builds > Pipeline to see your newly created pipeline running in OCP Land.  @@ -190,7 +206,7 @@ 2. With the configuration in place for the `todolist-fe`; repeat the process for the `todolist-api`. Update the `todolist-api/.openshift-applier/inventory/group_vars/all.yml` with a new object to drive the params and template ```yaml - name: todolist-ocp-pipeline - name: todolist-ocp-pipeline template: "{{ playbook_dir }}/templates/ocp-pipeline.yml" params: "{{ playbook_dir }}/params/ocp-pipeline" namespace: "{{ ci_cd_namespace }}" @@ -200,14 +216,14 @@ 2. Update the `todolist-api/.openshift-applier/params/ocp-pipeline` ``` PIPELINE_SOURCE_REPOSITORY_URL=https://gitlab-ci-cd.apps.somedomain.com/<YOUR_NAME>/todolist-api.git PIPELINE_SOURCE_REPOSITORY_URL=https://gitlab.apps.lader.rht-labs.com/<GIT_USERNAME>/todolist-api.git PIPELINE_SOURCE_REPOSITORY_REF=develop NAME=todolist-api ``` 2. Use the OpenShift Applier to create the cluster content ```bash $ cd .openshift-applier $ cd todolist-api/.openshift-applier $ ansible-playbook apply.yml -i inventory/ \ -e "filter_tags=pipeline" ``` @@ -215,22 +231,26 @@ 2. Login to your OpenShift Cluster and go to the `<YOUR_NAME>-ci-cd` namespace. On the side menu; hit Builds > Pipeline to see your newly created pipeline running in OCP Land.  2. Commit your changes to GitLab ```bash $ git add . $ git commit -m "ADD - ocp pipeline in git repo" $ git push ``` ### Part 3 - Security Scanning Slaves > _This exercise focuses on updating the `enablement-ci-cd` repo with some new jenkins-slave pods for use in future exercise_ #### Part 3a - OWASP ZAP #### 3a - OWASP ZAP > _OWASP ZAP (Zed Attack Proxy) is a free open source security tool used for finding security vulnerabilities in web applications._ 3. First we're going to take the generic jenkins slave template from our exercise4/zap branch and the params. 3. On your terminal; move to the `enablement-ci-cd` repo. We already have the `templates/jenkins-slave-generic-template.yml` template we're going to re-use from the previous lab so all we need is to check out the params file ```bash $ git checkout exercise4/zap-and-arachni params/ templates/jenkins-slave-generic-template.yml $ git checkout exercise4/zap-and-arachni params/jenkins-slave-zap ``` 3. This should have created the following files: - `templates/jenkins-slave-generic-template.yml` - `params/jenkins-slave-zap` and `params/jenkins-slave-arachni` 3. This should have created the following files which we will fill out. We will use a `ZAP` image hosted on the `rht-labs/ci-cd` repo so there will be no `Dockerfile` needed as we did with the `jenkins-slave-npm` in exercise 2: - `params/jenkins-slave-zap` 3. Create an object in `inventory/host_vars/ci-cd-tooling.yml` called `jenkins-slave-zap` and add the following content: ```yaml @@ -241,12 +261,7 @@ tags: - zap ``` <p class="tip"> NOTE- Install your Openshift Applier dependency if it's disappeared. ``` $ ansible-galaxy install -r requirements.yml --roles-path=roles ``` </p>  3. Run the ansible playbook filtering with tag `zap` so only the zap build pods are run. ```bash @@ -256,10 +271,15 @@ ``` 3. Head to (https://console.somedomain.com/console/project/<YOUR_NAME>-ci-cd/browse/builds) on Openshift and you should see `jenkins-slave-zap`. include screenshot here.  #### Part 3b - Arachni Scan #### 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. ```bash $ 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: ```yaml @@ -271,6 +291,22 @@ - arachni ``` 3. Update the params 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 BUILDER_IMAGE_NAME=registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7:latest NAME=jenkins-slave-arachni SOURCE_REPOSITORY_REF=master ``` 3. With these changes in place, push your changes to the `master` branch. ```bash $ git add . $ git commit -m "ADD - Arachni scanning image" $ git push ``` 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 \ exercises/images/exercise3/jenkinsfile-prep.png
New file @@ -0,0 +1,37 @@ # Introduction to Agile > Session to introduce the principles, values and practices of Agile. This will include a short interactive exercise to demonstrate some of the key agile practices we use in iterative delivery. _____ ## Slides The latest version of slides for the session are available [here](https://docs.google.com/presentation/d/1eYI04ChApbQd-a1b8GsBaRfGzuIm12AxYyi61fEE9G4/edit?usp=sharing) ## Facilitation Materials Needed * Teams in table size of 4 to 6 * Sticky Notes - set of the following on each table * Small Rectangular - lots of one color * Sharpie Pens on each table * Flip chart paper * Flip chart pens * Ping pong balls (100-150 in total for a group of 24) ## Facilitation Guidelines * Present the slides to introduce Agile values, principles and practices * This includes the 15 minute video by Henrik Kniberg, Product Ownership in a Nutshell. After playing this, a group discussion about what some of the memorable messages were * Run the Ball game as described on the slides: * 4 sprints in total * Radiate and capture estimates vs actuals * Look for trends in improved accuracy of estimation and increased overall velocity * At the end of Sprint 2, suggest each team does a review of other teams to see if they can learn new techniques from watching others in action * At the end of Sprint 3, calculate the team's overall velocity. Challenge them to triple this. Ask what would help bring up the overall velocity (answer is smaller teams). Run a 4th sprint where group can self organise into smaller teams (agree a team is more than one person) * Debrief the learnings
