Merge pull request #204 from rht-labs/minor-updates

Donal Spring

2018-05-01 db51a89b87b9f18826007fc130732200dfdcbb40

Merge pull request #204 from rht-labs/minor-updates

Minor updates

 README.md

@@ -1,5 +1,5 @@
# Red Hat Open Innovation Labs Enablement Materials
This repo will house all the slides and lab exercises for the Enablement course. It will also be used to track issues, features and new additions to the course.
This repo will house all the slides and lab exercises for the Enablement. It will also be used to track issues, features and new additions to the Enablement.

[Course Content](https://rht-labs.github.io/enablement-docs/#/)


 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.

![automation-xkcd](https://imgs.xkcd.com/comics/automation.png)

@@ -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.

![jenkins-time](../images/exercise2/jenkins-time.jpg)

@@ -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.
![jenkins-slave-npm-build](../images/exercise2/jenkins-slave-npm-build.png)

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>
@@ -683,7 +683,7 @@
> _In this exercise we will link GitLab to Jenkins so that new build jobs are triggered on each push to the `develop` branch._

<p class="tip" >
NOTE - This section is optional! Git webhooks are useful but not needed for course completion.
NOTE - This section is optional! Git webhooks are useful but not needed for Enablement completion.
</p>

7. In order to allow GitLab trigger Jenkins (because of the OpenShift Auth Plugin), we need to allow the `Anonymous` user trigger builds. Head to your Jenkins Dashboard and click on `Manage Jenkins` on the left hand side. Then scroll down and click `Configure Global Security`. Alternatively, type in `https://jenkins-<YOUR_NAME>-ci-cd.apps.some.domain.com/configureSecurity/` . You should see a screen like so:

 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.

![comic-header](../images/exercise3/comic-header.png)

@@ -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.
![rerun-all](../images/exercise3/rerun-all.png)

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.
![important-flag-before](../images/exercise3/important-flag-before.png)

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. 

![jenkins-fail-meme](../images/exercise4/jenkins-fail-meme.jpeg)

@@ -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, {

 facilitation/00-setup/README.md

New file
@@ -0,0 +1,74 @@
# Setting up the Enablement Session

> These notes are intended to evolve into a set of shared thoughts on how to set up and facilitate the Open Innovation Labs DevOps Culture and Practice Enablement.

_____


## Booking the space and facilities

Key requirements for the venue include:

* Desks in workshop format (5 tables of 4-5 people), ideally on wheels and movable (so we can go through the experience of teams configuring the space)
* Power socket banks for each table 
* LOTS of wall space (more than you could think.... we may need to supplement with "portable wall" boards) 
* Projector that supports HDMI
* Ability to play sound from laptop
* Strong WiFi (all delegates will need to be connected throughout the Enablement)
* At least one break out area - ideally a small room near the main room


## Shopping / Bring List

* Print Exercise Booklets - a PDF of all exercises. We have printed these in A4 color, double-sided with wire binding, a clear cover and black card back
* Card printouts of "The Big Picture" components
* Poster printouts of
    * Henrik Kniberg Product Ownership in a Nutshell
    * Henrik Kniberg Skateboard Picture
    * The Agile Manifesto Values and Principles
    * What DevOps is Not
* Some spare adapters for overseas' participants to connect laptops to power    
* Bluetac
* A1 Sticky Chart Paper
* Boards (especially if wall space is lacking)
* Post-it / sticky notes (variety of colors and sizes as described in the Facilitation Guides)
* Sharpies (enough for one per participant + a few extra)
* Whiteboard Pens - mixture of colors
* Magic Whiteboard (especially if there is a lack of whiteboard space in the venue)
* Painters' Tape - mixture of colors
* Bluetooth Speaker
* Fun activities (e.g. a mini golf set and mini ping pong set)
* Option to project build monitors (e.g. through Rasperry Pis) - organise extra monitors or bring projector
* Think about capturing the Enablement by bringing, for example, GoPro Camera, 360 cameera, etc.


## Setting up the Room

The day before the Enablement begins, get access to the room and lay out all materials. Specific things to set up include:
* Backlog
* Burndown
* Definition of Done
* Target Outcomes
* Realtime Retrospective
* Big Picture Area
* Practice Corner Area
* Ping Pong and Golf
* Labs is….
* Space for Faces
* Space for Animals

Think about the wall space that will be used for:
* Team's Social Contract
* Wider Group Social Contract
* Event Storming
* Metric Based Process Maps
* Value Slicing
* End of Day Retros


## Facilitation Guidelines

* Facilitation Guides have been prepared for each of the exercises (technical and non-technical). These are intended to be living and breathing documents which will be updated as more Enablement sessions are run.
* Slideware includes lots of real world residency examples of practices being taught. It is expected that these examples will change session-by-session and the Labs facilitators will inject their own stories, photos and videos in here.
* Catering is an important factor to consider. Having group breakfasts and lunch emulates what we do on Residencies
* Having a group social during the week is also an important aspect of the Enablement