| exercises/0-rogue-cluster/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/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/images/exercise3/TDD-lifecycle.jpg | patch | view | raw | blame | history | |
| exercises/images/exercise3/comic-header.png | patch | view | raw | blame | history | |
| exercises/images/exercise4/builds-zap-arachni.png | patch | view | raw | blame | history | |
| exercises/images/exercise4/jabbas-palace.jpg | patch | view | raw | blame | history | |
| exercises/images/jabbas-palace.jpg | patch | view | raw | blame | history |
exercises/0-rogue-cluster/README.md
@@ -22,6 +22,6 @@ - Learners have access to LDAP bind credentials to be able to auth against gitlab - ## User privaleges - Learners will require privaleges to run SCC containers ie GitLab ## User privileges - Learners will require privileges to run SCC containers ie GitLab - exercises/2-attack-of-the-pipelines/README.md
@@ -62,11 +62,19 @@ ### 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 2. Git clone the `todolist-fe` project to somewhere sensible and checkout the `develop` branch. ```bash $ git clone https://github.com/springdo/todolist-fe.git $ cd todolist-fe $ git checkout develop ``` Followed by; ``` $ for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master`; do git branch --track ${branch#remotes/origin/} $branch done ``` 2. Open up Gitlab and login. Create a new project (internal) in GitLab called `todolist-fe` to host your clone of the project and copy it's remote address.  @@ -106,7 +114,7 @@ * The server hosting it live reloads; so as you make changes to your code; the app will live update * The Data you see in the screen is dummy / stubbed data. This is served up when there is no backend connection found 2. The app is a todolist manager built in Vue.js. Play around with the App. You will notice when you add todos they appear and clear as expected. If you refresh the page you'll loose all additions. This is because there is persistence 2. The app is a todolist manager built in Vue.js. Play around with the App. You will notice when you add todos they appear and clear as expected. If you refresh the page you'll lose all additions. This is because there is persistence 3. The structure of the `todolist-fe` is as follows. ```bash @@ -152,12 +160,29 @@ * `./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. ```bash export NEXUS_SERVICE_HOST=nexus-<YOUR_NAME>-ci-cd.apps.somedomain.com export NEXUS_SERVICE_PORT=80 npm run prepare-nexus ``` <p class="tip"> 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 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 $ git clone https://github.com/springdo/todolist-api.git $ git cd todolist-api $ git checkout develop ``` Followed by; ``` $ for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master`; do git branch --track ${branch#remotes/origin/} $branch done ``` 2. Create a new project (internal) in GitLab called `todolist-api` to host your clone of the project and copy it's remote address. @@ -234,15 +259,6 @@ }, ``` 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. ```bash export NEXUS_SERVICE_HOST=nexus-<YOUR_NAME>-ci-cd.apps.somedomain.com export NEXUS_SERVICE_PORT=80 npm run prepare-nexus ``` <p class="tip"> NOTE - This step in a residency would be automated by a more complex nexus deployment in the ci-cd project </p> 2. To run the application; start a new instance of the MongoDB by running. ```bash @@ -431,7 +447,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 andi t 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 and set `Max # of builds to keep with artifacts` to 1 as 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 and set `Max # of builds to keep with artifacts` to 1 as below  5. Our NodeJS build needs to be run on the `jenkins-slave-npm` we created earlier. Specify this in the box labelled `Restrict where this project can be run` 
@@ -1,6 +1,45 @@ # Exercise Title # Revenge Of The Automated Testing > The purpose of this lab is to develop and validate a new feature using TDD; and to promote the assured feature through the pipeline.  [Image Source](https://cdn-images-1.medium.com/max/1600/1*wF_fSCH-gLYfMbkwb3gR2w.png) ## Introduction to TDD. > _Here is a brief introduction of TDD and why we use it._ **Test Driven Development (TDD)** is a software development process that relies on the repetition of a very short development cycle. Requirements are turned into test cases, where the software is developed to pass the tests. In other words, it creates a safety net that serves to keep the developer's problems/bugs at bay while enabling the developer to refactor efficiently. This is opposed to software development that allows software to be added that is not proven to meet requirements. The TDD cycle can be illustrated with the following diagram;  ### 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. 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. 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. 4. `Code Passes tests` - If all tests pass, the developer can be confident that the new code meets the test requirements. 5. `Refactor` - The refactoring step will allow the developer to clean up their code without changing its behaviour. Not changing the behaviour should ensure the tests still pass. The process of refactoring can include; removal of duplication, renaming of Object, class, module, variable and method names to clearly represent their current purpose and use, decoupling of functionality and increasing code cohesion. 6. `Repeat` - 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.  * `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. --- @@ -49,10 +88,8 @@ ## Step by Step Instructions > This is a fairly structured guide with references to exact filenames and sections of text to be added. ### Part 1 - Tests in our Pipeline > _In this exercise we will 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_ > _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 - Unit tests > In this exercise we will execute our test for the frontend and backend locally. Once verified we will add them to Jenkins. @@ -65,36 +102,38 @@ <p class="tip" > `test` is an alias used that runs `vue-cli-service test` from the scripts object in `package.json` </p>   2. This command will run all `*spec.js` files. Our test files are stored in the following places. There are 12 Frontend test files stored in these directories: `todolist-fe/tests/unit/vue-components/*` & `todolist-fe/tests/unit/javascript/*` 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. 2. Repeat the same process for `todolist-api` and verify that all the tests run. There are 2 Api test files: `todolist-api/server/api/todo/todo.spec.js` & `todolist-api/server/mocks/mock-routes.spec.js` ```bash $ cd todolist-api $ npm run test ``` 2. Navigate to your instance of jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.s8.core.rht-labs.com/`. 2. Navigate to your instance of jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.somedomain.com/`. Click on `dev-todolist-fe-build` and then click the `configure` button on the left-hand side.   2. Scroll to the `Build` part of the configuration page and add `scl enable rh-nodejs8 'npm run test'` below `scl enable rh-nodejs8 'npm install'`. Click `save` or `apply` at the bottom to save the changes.   2. Scroll to the `Post-build Actions` section and click `Add post-build action`. Select `Publish xUnit test result report`.   2. Click the `Add` button under `Publish xUnit test result report` and select `JUnit`. In the pattern field enter `test-report.xml`. In the `Failed Tests Thresholds` input box enter 0 under `Red Ball Total`. It should look a little something like this:   2. Click `save` or `apply` at the bottom to save the changes. Rerun the `dev-todolist-fe-build` job and verify that this passes and the `build` and `bake` jobs are both triggered. 2. Click `save` or `apply` at the bottom to save the changes. Run the `dev-todolist-fe-build` job and verify that this passes and the `build` and `bake` jobs are both triggered. 2. We're now going to deliberately fail a test to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Go to `ListOfTodos.spec.js` in `/tests/unit/vue-components` and head to `line 38`. Add `not.` before `toHaveBeenCalled()`.   2. Push this to Gitlab and rerun the build job. 2. Push this to Gitlab and run the build job. ```bash $ git add . $ git commit -m "Deliberately failed test to test the pipeline stops me deploying broken code" @@ -102,31 +141,35 @@ ``` 2. Rerun the `dev-todolist-fe-build` job. It should have failed and not run any other builds.   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`. 2. We're now going to do the same for the api. Head to the `configure` panel of the `dev-todolist-api-build` job. 2. Add `scl enable rh-nodejs8 'npm run test:ci'` above `npm run build:ci`.   2. Scroll to the `Post-build Actions` section and click `Add post-build action`. Select `Publish xUnit test result report`. 2. Click the `Add` button under `Publish xUnit test result report` and select `JUnit`. In the pattern field enter `reports/server/mocha/test-results.xml`. In the `Failed Tests Thresholds` input box enter 0 under `Red Ball Total`. It should look a little something like this:   2. We're now going to deliberately fail a test again to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Go to `todo.spec.js` in `/server/api/todo` and head to `line 35`. Replace `false` with `true`.   2. Push this to Gitlab and rerun the build job. 2. Push this to Gitlab and run the build job. ```bash $ git add . $ git commit -m "Deliberately failed test to test the pipeline stops me deploying broken code" $ git push ``` 2. If successful this will fail the build and not run the `bake` or `deploy` jobs. Don't forget to remove the changes that you made to your tests! 2. If successful this will fail the build and not run the `bake` or `deploy` jobs. <p class="tip"> NOTE - Don't forget to undo the changes that you made to your tests! </p> #### Part 1b - 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._ exercises/4-an-enslaved-hope/README.md
@@ -21,6 +21,8 @@ 1. [Pipeline](https://jenkins.io/doc/book/pipeline/) - Overview of the Jenkinsfile approach 1. [Pipeline Syntax](https://jenkins.io/doc/book/pipeline/syntax/) - Documentation for the declarative pipeline 1. [Groovy](http://groovy-lang.org/) - Groovy is a powerful, optionally typed and dynamic language, with static-typing and static compilation capabilities, for the Java platform aimed at improving developer productivity thanks to a concise, familiar and easy to learn syntax. It integrates smoothly with any Java program, and immediately delivers to your application powerful features, including scripting capabilities, Domain-Specific Language authoring, runtime and compile-time meta-programming and functional programming. 1. [Zed Attack Proxy](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) - The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers*. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. Its also a great tool for experienced pentesters to use for manual security testing. 1. [Arachni Crawler](http://www.arachni-scanner.com/) - Arachni is a feature-full, modular, high-performance Ruby framework aimed towards helping penetration testers and administrators evaluate the security of modern web applications. It is free, with its source code public and available for review. It is versatile enough to cover a great deal of use cases, ranging from a simple command line scanner utility, to a global high performance grid of scanners, to a Ruby library allowing for scripted audits, to a multi-user multi-scan web collaboration platform. In addition, its simple REST API makes integration a cinch. ## Big Picture This exercise begins cluster containing blah blah @@ -147,12 +149,72 @@ 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.  3. Run the jobs and validate the app is working as expected in the `test` environment! 2. Run the jobs and validate the app is working as expected in the `test` environment! ### Part 2 - Security Scanning Slaves > _This exercise focuses on updating the `enablement-ci-cd` repo with some new jenkins-slave pods for use in future exercise_ 3. TODO! #### Part 2a - 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 ``` 3. This should have created the following files: - `templates/jenkins-slave-generic-template.yml` - `params/zap-build-pod` and `params/arachni-build-pod` 3. Create an object in `inventory/host_vars/ci-cd-tooling.yml` called `zap-build-pod` and add the following content: ```yaml - name: "zap-build-pod" namespace: "{{ ci_cd_namespace }}" template: "{{ playbook_dir }}/templates/jenkins-slave-generic-template.yml" params: "{{ playbook_dir }}/params/zap-build-pod" 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 $ ansible-playbook apply.yml -e target=tools \ -i inventory/ \ -e "filter_tags=zap" ``` 3. Head to (https://console.somedomain.com/console/project/<YOUR_NAME>-ci-cd/browse/builds) on Openshift and you should see `zap-build-pod`. include screenshot here. #### Part 2b - 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 `arachni-build-pod` with the following content: ```yaml - name: "arachni-build-pod" namespace: "{{ ci_cd_namespace }}" template: "{{ playbook_dir }}/templates/jenkins-slave-generic-template.yml" params: "{{ playbook_dir }}/params/arachni-build-pod" tags: - arachni ``` 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.somedomain.com/console/project/<YOUR_NAME>-ci-cd/browse/builds) on Openshift and you should see `arachni-build-pod`.  _____
@@ -10,7 +10,8 @@ - Ansible v2.5 - NodeJS v8.x - Git Installed - Google Chrome Web Browser - Google Chrome Web Browser (>59) - Docker 17.x - Access to an OpenShift cluster `oc login -u <username> -p <password> <cluster_url>` > (TODO) Download the tools-container containing required Ansible and OpenShift tooling pre-installed exercises/images/exercise3/TDD-lifecycle.jpg
