| 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/1-the-manual-menace/README.md
@@ -1,5 +1,5 @@ # The Manual Menace > In this lab 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.  @@ -41,7 +41,7 @@ _____ ## 10,000 Ft View > This lab 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 highlevel 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: @@ -66,7 +66,7 @@ ### Part 1 - Create OpenShift Projects > _Using the OpenShift Applier, we will add new project namespaces to the cluster which will be used throughout the exercise._ 3. Clone the scaffold project to your local machine and pull all remote branches for use in later labs. Open the repo in your favourite editor. 3. Clone the scaffold project to your local machine and pull all remote branches for use in later exercises. Open the repo in your favourite editor. ```bash $ git clone https://github.com/rht-labs/enablement-ci-cd && cd enablement-ci-cd ``` exercises/2-attack-of-the-pipelines/README.md
@@ -1,6 +1,6 @@ # Attack of the Pipelines > In this lab we will explore the sample TODO List application and create a pipeline in Jenkins to build and deploy our code. > In this exercise we will explore the sample TODO List application and create a pipeline in Jenkins to build and deploy our code.  @@ -167,7 +167,7 @@ where the following are the important things: * `./src` is the main collection of files needed by the app. The entrypoint is the `main.js` which is used to load the root `App.vue` file. * `./node_modules` is where the dependencies are stored * `./test` contains our end-to-end tests and unit tests. More covered on these in later labs. * `./test` contains our end-to-end tests and unit tests. More covered on these in later exercises. * `./src/components` contains small, lightweight reusable components for our app. For example, the `NewTodo` component which encapsulates the styling, logic and data for adding a new todo to our list * `./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. @@ -251,7 +251,7 @@ * `./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. * `./tasks` is a collection of additional `Grunt` tasks which will be used in later labs * `./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 @@ -351,7 +351,7 @@ 3. Verify the build executed successfully by logging into the cluster and checking the `builds` tab of the `<YOUR_NAME>-ci-cd` project.  3. You should now be able to apply the label `jenkins-slave-npm` to a build job to run a build on this newly created slave as we will see in the rest of this lab 3. You should now be able to apply the label `jenkins-slave-npm` to a build job to run a build on this newly created slave as we will see in the rest of this exercise <p class="tip"> NOTE - Jenkins may need to be restarted for the configuration to appear. To do this; navigate to your jenkins instance and add `/restart` to the url. </p> exercises/3-revenge-of-the-automated-testing/README.md
@@ -1,6 +1,6 @@ # 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. > The purpose of this exercise is to develop and validate a new feature using TDD; and to promote the assured feature through the pipeline.  @@ -151,7 +151,7 @@ #### 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. 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 exercise. ```bash $ git checkout exercise3/mongodb params/mongodb templates/mongodb.yml ``` @@ -410,7 +410,7 @@ 3. All the tests should be passing when we begin. If `No tests found related to files changed since last commit` is on show; hit `a` on the terminal to re-run `all` tests.  3. There are three places we will add new tests to validate our function behaves as expected against the acceptance criteria from the Feature Story supplied to us. We will need to write tests for our `TodoItem.vue` to handle having a red flag and that it is clickable. Our app is going to need to persist the changes in the backend so we'll want to make changes to our `actions.js` and `mutations.js` to keep the api and local copy of the store in sync. Let's start with our `TodoItem.vue` component. Open the `tests/unit/vue-components/TodoItem.spec.js` file. This has been templated with some example test to correspond with our A/Cs for speed of doing the lab. Find the describe block for our important flag tests. It is setup already with a `beforeEach()` hook for test setup. 3. There are three places we will add new tests to validate our function behaves as expected against the acceptance criteria from the Feature Story supplied to us. We will need to write tests for our `TodoItem.vue` to handle having a red flag and that it is clickable. Our app is going to need to persist the changes in the backend so we'll want to make changes to our `actions.js` and `mutations.js` to keep the api and local copy of the store in sync. Let's start with our `TodoItem.vue` component. Open the `tests/unit/vue-components/TodoItem.spec.js` file. This has been templated with some example test to correspond with our A/Cs for speed of doing the exercise. Find the describe block for our important flag tests. It is setup already with a `beforeEach()` hook for test setup.  3. Each of our test cases has it's skeleton in place already for example the `TodoItem.vue` component takes a property of `todos` when rendering. This setup is already done for each of our tests so all we have to do is fill in our assertions. @@ -471,7 +471,7 @@ 3. Underneath the `</md-list-item>` tag, let's add a new md-button. Add a `.important-flag` class on the `md-button` and put the svg of the flag provided inside it. ```html </md-list-item> <!-- TODO - SVG for use in Lab3 --> <!-- TODO - SVG for use in Exercise3 --> <md-button class="important-flag"> <svg height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" ><path d="M0 0h24v24H0z" fill="none"/><path d="M14.4 6L14 4H5v17h2v-7h5.6l.4 2h7V6z"/></svg> </md-button> @@ -487,7 +487,7 @@ 3. More tests should now be passing. Let's wire the click of the flag to an event in Javascript. In the methods section of the `<script></script>` tags in the Vue file, implement the `markImportant()`. We want to wire this to the action to updateTodo, just like we have in the `markCompleted()` call above it. We also need to pass and additional property to this method call `important` ```javascript markImportant() { // TODO - FILL THIS OUT IN THE LAB EXERCISE // TODO - FILL THIS OUT IN THE EXERCISE this.$store.dispatch("updateTodo", {id: this.todoItem._id, important: true}); console.info("INFO - Mark todo as important ", this.todoItem.important); }, @@ -496,7 +496,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 --> <!-- TODO - SVG for use in Exercise3 --> <md-button class="important-flag" @click="markImportant()"> <svg :class="{'red-flag': todoItem.important}" height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg" ><path d="M0 0h24v24H0z" fill="none"/><path d="M14.4 6L14 4H5v17h2v-7h5.6l.4 2h7V6z"/></svg> </md-button> exercises/4-an-enslaved-hope/README.md
@@ -1,6 +1,6 @@ # 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 labs. > 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.  @@ -15,7 +15,7 @@ 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 - Create Jenkins slave nodes for use in builds in future labs - Create Jenkins slave nodes for use in builds in future exercises ## Tools and Frameworks > Name of tool - short description and link to docs or website @@ -32,7 +32,7 @@ _____ ## 10,000 Ft View > The goal of this exercise is to move to using the Jenkinsfile in the todolist-api and todolist-fe projects. Additionally we will create new slaves for use in the next lab > The goal of this exercise is to move to using the Jenkinsfile in the todolist-api and todolist-fe projects. Additionally we will create new slaves for use in the next exercise. 2. On Jenkins; create a multibranch pipeline project to scan the GitLab endpoint for each app. Use the Jenkinsfile provided to run the stages. Replace the `<YOUR_NAME>` with appropriate variable. @@ -42,7 +42,7 @@ > 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 Lab 2 with a Jenkinsfile approach_ > _In this exercise we'll replace the Pipeline we created in Exercise 2 with a Jenkinsfile approach_ 2. On your terminal navigate to your `todolist-api` project and checkout the pipeline feature branch that's been already created for you. ```bash @@ -61,7 +61,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. 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. 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 environment { // GLobal Vars exercises/5-non-functionals-strike-back/README.md
@@ -37,7 +37,7 @@ - Do some light performance testing to monitor throughput of APIs ## Tools and Frameworks > Below is a collection of the new frameworks and tools that will be used in this lab > Below is a collection of the new frameworks and tools that will be used in this exercise 1. [eslint](https://eslint.org/) - ESLint is an open source JavaScript linting utility originally created by Nicholas C. Zakas in June 2013. Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines. There are code linters for most programming languages, and compilers sometimes incorporate linting into the compilation process. 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. exercises/6-return-of-the-app-monitoring/README.md
@@ -7,7 +7,7 @@ ## Exercise Intro Build monitors provide a tight feedback loop which is vital to high performing teams. Being in a highly visible location, build monitors radiate crucial build and test information, meaning the team doesn't have to go out of their way to find it. Build monitors also provide a degree of accountability whilst also keeping the team motivated to fix problems. With broken components visualised, seeing build monitors change from red to green can give the collective feeling that progress is being made. On residencies we display the build monitors on Raspberry Pi's hooked up to large TV screens that everyone can see at a glance. We've also used colour-changing lightbulbs in the labs that change from Green to Red depending on the success/fail status of jobs. There are many other ways to notify people of Build Failures such as Slack notices, text messages or just plain old email. This lab is about radiating the information to allow teams respond quickly to change. On residencies we display the build monitors on Raspberry Pi's hooked up to large TV screens that everyone can see at a glance. We've also used colour-changing lightbulbs in the labs that change from Green to Red depending on the success/fail status of jobs. There are many other ways to notify people of Build Failures such as Slack notices, text messages or just plain old email. This exercise is about radiating the information to allow teams respond quickly to change. In this Exercise we will be creating a build monitor to display all of our jobs in one visual display as well as pipeline views. We will then add the cause of build failures for each job to the monitors. This will allow you to rapidly see why a particular build is failing and fix it faster. @@ -86,7 +86,7 @@ 2. Open the `todolist-fe` app in your favourite editor. In this exercise, we will fail a test and capture the message in the log and visualise it on a dashboard. 2. Open one of the tests you wrote in previous labs; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file by adding a `.not` to the `expect()` statement as shown below. 2. Open one of the tests you wrote in previous exercises; for example `tests/unit/vue-components/TodoItem.spec.js`. Negate the test at the very bottom of the file by adding a `.not` to the `expect()` statement as shown below. ```javascript it("call makImportant when clicked", () => { const wrapper = mount(TodoItem, {
