| 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/images/exercise4/todolist-test.png | patch | view | raw | blame | history |
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 @@ -374,7 +374,7 @@ $ npm run start ``` #### Part 2b - Create todolist-fe tests #### 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 fronted 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. @@ -581,7 +581,7 @@ 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 !!
@@ -191,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.  @@ -199,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 }}" @@ -216,7 +223,7 @@ 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" ``` @@ -224,17 +231,23 @@ 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. ```bash $ git checkout exercise4/zap-and-arachni params/ templates/jenkins-slave-generic-template.yml $ git checkout exercise4/zap-and-arachni params/ templates/jenkins-slave-generic-template.yml ``` 3. This should have created the following files: @@ -267,7 +280,7 @@ 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. Create an object in `inventory/host_vars/ci-cd-tooling.yml` called `jenkins-slave-arachni` with the following content: exercises/images/exercise4/todolist-test.png
