acammies
2018-04-10 8f75582e133d7375a691e1e33c1657df5060f3f3
commit | author | age
2b8436 1 # Attack of the Pipelines
c951f7 2
2b8436 3 > In this lab we will explore the sample TODO List application and create a pipeline in Jenkins to build and deploy our code.
D 4
5 ![jenkins-time](../images/exercise2/jenkins-time.jpg)
6
43f2f2 7 _____
c951f7 8
D 9 ## Learning Outcomes
2b8436 10 As a learner by the end of this lesson you will be able to
D 11
12 - Build and run the full stack of the TODO List application locally
13 - Create an un-gated pipeline using the Jenkins UI for the backend and frontend
14 - Add branching to the pipeline to target specific namespace
c951f7 15
D 16 ## Tools and Frameworks
2b8436 17 > The following tools are used throughout this exercise. Familiarity with them is not required but knowing what they are may help!
c951f7 18
D 19 1. [Jenkins](https://jenkins.io/) - OpenSource build automation server; highly customisable through plugins
2b8436 20 1. [NodeJS](https://nodejs.org/en/) - Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js' package ecosystem, npm, is the largest ecosystem of open source libraries in the world.
D 21 1. [MongoDB](https://www.mongodb.com/what-is-mongodb) - MongoDB stores data in flexible, JSON-like documents, meaning fields can vary from document to document and data structure can be changed over time
22 1. [VueJS](https://vuejs.org/) - Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. It is designed from the ground up to be incrementally adoptable, and can easily scale between a library and a framework depending on different use cases. It consists of an approachable core library that focuses on the view layer only, and an ecosystem of supporting libraries that helps you tackle complexity in large Single-Page Applications.
c951f7 23
43f2f2 24 ## Big Picture
2b8436 25 > From the previous exercise; we created some supporting tooling needed by our app/
43f2f2 26
D 27 _____
c951f7 28
D 29 ## 10,000 Ft View
2b8436 30 > _This lab requires users to take the sample TODO app and create a build pipeline in Jenkins by clicking your way to success ending up with an app deployed to each of the namespaces created previously_
43f2f2 31
2b8436 32 2. Import the projects into your gitlab instance. See README of each for build instructions
43f2f2 33
2b8436 34 2. Deploy a `MongoDB` using the provided template to all project namespace.
D 35
36 2. Create 2 pipline with three stages (`build`, `bake`, `deploy`) in jenkins for `develop` & `master` branches on the `todolist-fe` such that:
e919d0 37     * a `Build` job is responsible for compiling and packaging our code:
2b8436 38         1. Checkout from source code (`develop` for `<yourname>-dev` & `master` for `<yourname>-test`)
D 39         2. Install node dependencies and run a build / package
e919d0 40         3. Send the package to Nexus
D 41         4. Archive the workspace to persist the workspace in case of failure
42         4. Tag the GitLab repository with the `${JOB_NAME}.${BUILD_NUMBER}` from Jenkins. This is our `${BUILD_TAG}` which will be used on downstream jobs.
43         5. Trigger the `bake` job with the `${BUILD_TAG}` param
44     * a `Bake` job should take the package and put it in a Linux Container
2b8436 45         1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`.
D 46         2. Checkout the binary from Nexus and unzip it's contents
e919d0 47         3. Run an oc start-build of the App's BuildConfig and tag it's imagestream with the provided `${BUILD_TAG}`
2b8436 48         4. Trigger a deploy job using the parameter `${BUILD_TAG}`
e919d0 49     * a `deploy` job should roll out the changes by updating the image tag in the DC:
2b8436 50         1. Take an input of the `${BUILD_TAG}`
D 51         2. Patch / set the DeploymentConfig to the image's `${BUILD_TAG}`
52         3. Rollout the changes
53         4. Verify the deployment
54
55 2. Repeat the above setup for the backend `todolist-fe`. TIP - use the copy config to speed things up!
56
57 2. Verify that both apps and the DB are talking to one another as expected.
c951f7 58
D 59 ## Step by Step Instructions
7383de 60 > This is a fairly structured guide with references to exact filenames and sections of text to be added.
c951f7 61
7383de 62 ### Part 1 - Explore the Sample App
D 63 > _In this part of the exercise we will explore the sample application, become familiar with it locally before building and deploying in OCP Land_
43f2f2 64
7383de 65 2. Git clone the `todolist-fe` project to somewhere sensible and checkout the `develop` branch.
D 66 ```bash
67 $ git clone https://github.com/springdo/todolist-fe.git
68 $ git checkout develop
c951f7 69 ```
7383de 70
D 71 2. Create a new project (internal) in GitLab called `todolist-fe` to host your clone of the project and copy it's remote address. ![new-gitlab-proj](../images/exercise2/new-gitlab-proj.png)
72
73 2. In your local clone of the `todolist-fe`, remove the origin and add the GitLab origin by replacing `<YOUR_GIT_LAB_PROJECT>`. Push your app to GitLab
74 ```bash
75 $ git remote remove origin
76 $ git remote add origin <YOUR_GIT_LAB_PROJECT>
77 $ git push -u origin --all
c951f7 78 ```
7383de 79
D 80 2. To get the app running locally; first check you've got node and npm installed
81 ```bash
82 $ node -v
83 $ npm -v
84 ```
85 <p class="tip" > 
86 NOTE - If you are missing these dependencies; install them with ease using the [Node Version Manager](https://github.com/creationix/nvm)
87 </p>
88 ![node-version](../images/exercise2/node-version.png)
89
90 2. The `todolist-fe` has a package.json at the root of the project, this defines some configuration for the app including it's dependencies, dev dependencies, scripts and other configuration. Install the apps dependencies
91 ```bash
92 $ npm install
93 ```
94
76d54e 95 2. The `todolist-fe` has some scripts defined in the package.json at the root of the project. To run any of these scripts run `npm run <SCRIPT_NAME>`. Let's start by serving our application
7383de 96  ![npm-scripts](../images/exercise2/npm-scripts.png)
D 97 ```bash
98 npm run serve
99 ```
100
101 2. This will take sometime to execute; but once done it should open the browser for you displaying the `todolist-fe` app.
102  ![todo-list-app](../images/exercise2/todo-list-app.png)
103     * The server hosting it live reloads; so as you make changes to your code; the app will live update
104     * The Data you see in the screen is dummy / stubbed data. This is served up when there is no backend connection found
105
d2e708 106 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
7383de 107
D 108 3. The structure of the `todolist-fe` is as follows.
109 ```bash
110 todolist-fe
111 ├── jest.config.js
112 ├── jsconfig.json
113 ├── nightwatch.config.js
114 ├── node_modules
115 ├── package.json
116 ├── public
117 │   ├── favicon.ico
118 │   ├── img
119 │   ├── index.html
120 │   └── manifest.json
121 ├── src
122 │   ├── App.vue
123 │   ├── assets
124 │   ├── components
125 │   ├── config
126 │   ├── main.js
127 │   ├── registerServiceWorker.js
128 │   ├── router.js
129 │   ├── scss
130 │   ├── services
131 │   ├── store
132 │   └── views
133 ├── tests
134 │   ├── e2e
135 │   └── unit
136 └── vue.config.js
137 ```
138 where the following are the important things:
139     * `./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.
140     * `./node_modules` is where the dependencies are stored
141     * `./test` contains our end-to-end tests and unit tests. More covered on these in later labs.
142     * `./src/components` contains small, lightweight reusable components for our app. These include the `NewTodo` component which encapsulates the styling, logic and data for adding a new todo to our list
143     * `./src/store` is the `vuex` files for managing application state and backend connectivity
144     * `./src/views` is the view containers; which are responsible for loading components and managing their interactions.
145     * the `./src/router.js` controls routing logic. In our case the app only has one real endpoint.
146     * `./src/scss` contains custom  SCSS used in the application.
147     * `./*.js` is mostly config files for running and managing the app and the tests
c951f7 148
d2e708 149 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.
D 150 ```bash
151 $ git clone https://github.com/springdo/todolist-api.git
152 $ git checkout develop
153 ```
154
155 2. Create a new project (internal) in GitLab called `todolist-api` to host your clone of the project and copy it's remote address.
156
157 2. In your local clone of the `todolist-api`, remove the origin and add the GitLab origin by replacing `<YOUR_GIT_LAB_PROJECT>`. Push your app to GitLab
158 ```bash
159 $ git remote remove origin
160 $ git remote add origin <YOUR_GIT_LAB_PROJECT>
161 $ git push -u origin --all
162 ```
163
164 2. Once pushed; explore the application. It is a NodeJS application with the Express.js framework and MongoDB for persistent storage. Same as before, the `package.json` defines most of the configuration etc. Install the dependencies
165 ```bash
166 $ npm i
167 ```
168
169 2. While the dependencies are being installed; explore the project structure.
170 ```bash
171 todolist-api
172 ├── Dockerfile
173 ├── Gruntfile.js
174 ├── README.md
175 ├── node_modules
176 ├── package-lock.json
177 ├── package.json
178 ├── server
179 │   ├── api
180 │   │   └── todo
181 │   ├── app.js
182 │   ├── components
183 │   │   └── errors
184 │   ├── config
185 │   │   ├── environment
186 │   │   ├── express.js
187 │   │   ├── local.env.sample.js
188 │   │   └── seed.js
189 │   ├── mocks
190 │   │   ├── mock-routes-config.json
191 │   │   ├── mock-routes.js
192 │   │   └── mock-routes.spec.js
193 │   ├── routes.js
194 │   └── views
195 │       └── 404.html
196 └── tasks
197     └── perf-test.js
198 ```
199 where the following are the important things:
200     * `./server` is the main collection of files needed by the app. The entrypoint is the `app.js`
201     * `./node_modules` is where the dependencies are stored
202     * `./server/api` is where the api's controller, data model & unit test are stored. 
203     * `./server/mocks` is a mock server used for when there is no DB access    
204     * `./server/config` stores our Express JS config, header information and other middlewear.
205     * `./server/config/environment` stores enviromnent specific config; such as connectivity to backend services like the MongoDB.
206     * `./tasks` is a collection of additional `Grunt` tasks which will be used in later labs
207     * `package.json` contains the dependency list and a lot of very helpful scripts for managing the app lifecycle
208
209 2. The npm scripts are shown below. There are application start scripts, build and test items which will be used in the build. The ones for MongoDB are just provided for convenience and require Docker installed to execute.
210 ```json
211   "scripts": {
212     "start": "node server/app.js",
213     "dev": "./node_modules/.bin/grunt serve",
214     "jshint": "./node_modules/.bin/grunt jshint",
215     "jshint:ci": "./node_modules/.bin/grunt jshint:ci_server",
216     "clean": "rm -rf reports package-contents*",
217     "build": "mkdir -p package-contents && cp -vr server Dockerfile package.json package-contents",
218     "package": "zip -r package-contents.zip package-contents",
219     "test": "node_modules/.bin/nyc node_modules/.bin/mocha server/**/*.spec.js --exit",
220     "test:ci": "export MOCHA_FILE='reports/server/mocha/test-results.xml' && export NODE_ENV=ci && node_modules/.bin/nyc node_modules/.bin/mocha server/**/*.spec.js -R mocha-junit-reporter --exit",
221     "mongo" : "docker run -i -d --name mongo-local -p 27017:27017 mongo",
222     "mongo:drop" : "npm run mongo:stop && docker rm mongo-local",
223     "mongo:stop" : "docker stop mongo-local",
224     "mongo:start" : "docker start mongo-local"
225   },
226 ```
227
228 2. To run the application; start a new instance of the MongoDB by running. 
229 ```bash
230 $ npm run mongo
231 ```
232 <p class="tip">
233 `npm run mongo:drop` is used to completely remove the running container. `npm run mongo:stop` & `npm run mongo:start` will preserve data in the container
234 </p>
235
236 2. Fire up the `todolist-api` by running.
237 ```bash
238 $ npm run start
239 ```
240 ![node-app-started](../images/exercise2/node-app-started.png)
241
242 2. Check things are responding correctly by running and checking the response. It contains some seeded data (stored in `server/config/seed.js`)
243 ```bash
244 $ curl localhost:9000/api/todos
245 ```
246 ```json
247 [{
248     "_id": "5ac8ff1fdfafb02138698948",
249     "title": "Learn some stuff about MongoDB",
250     "completed": false,
251     "__v": 0
252   },
253   {
254     "_id": "5ac8ff1fdfafb02138698949",
255     "title": "Play with NodeJS",
256     "completed": true,
257     "__v": 0
258 }]
259 ```
260
261 2. Now let's check out `todolist-fe` app by reloading the browser. We should now see our dummy front end data is replaced by the backend seed data 
262 ![fullstack-app](../images/exercise2/fullstack-app.png)
263
264
9fc88c 265 ### Part 2 - Create a NodeJS Build slave
399baa 266 > _In this exercise; we will create a build configuration to generate a slave for Jenkins to use in it's builds_
9fc88c 267
399baa 268 3. In order for Jenkins to be able to run `npm` builds and installs as we have done locally, we must configure a `jenkins-build-slave` for Jenkins to use. This slave will be dynamically provisioned when we run a build. It needs to have NodeJS and npm installed in it. In your `enablement-cd-cd` repository, checkout the template and configuration. This will bring in the template, the params & the `Dockerfile`.
9fc88c 269 ```bash
D 270 $ git checkout exercise2/jenkins-slave docker/ templates/ params/
271 ```
272
273 3. Open the `params/jenkins-slave-npm` file and update `<YOUR_ENABLEMENT_GIT_REPO>` accordingly. This set of parameters will clone from the enablement repo and run a docker build of the Dockerfile stored in `docker/jenkins-slave-npm`.
274 ```bash
275 SOURCE_REPOSITORY_URL=<YOUR_ENABLEMENT_GIT_REPO>
276 SOURCE_CONTEXT_DIR=docker/jenkins-slave-npm
277 NAME=npm-jenkins-slave
278 ```
279
280 3. Create an item in the ansible variables file under the `ci-cd-builds` object to run the template with. Don't forget to substitute `<YOUR_NAME>`
281 ```yaml
282   - name: "jenkins-npm-slave"
283     namespace: "<YOUR_NAME>-ci-cd"
284     template: "{{ inventory_dir }}/../templates/jenkins-slave-generic-template.yml"
285     params: "{{ inventory_dir }}/../params/jenkins-slave-npm"
286     tags:
287     - jenkins-slave
288 ```
289 ![jenkins-slave-ansible](../images/exercise2/jenkins-slave-ansible.png)
290
291 3. Run the OpenShift Applier to trigger a build of this jenkins slave image.
292 ```bash
293 $ ansible-playbook roles/openshift-applier/playbooks/openshift-cluster-seed.yml \
294      -i inventory/ \
295      -e "filter_tags=jenkins-slave"
296 ```
297
298 3. Verify the build executed successfully by logging into the cluster and checking the `builds` tab of the `<YOUR_NAME>-ci-cd` project.
299 ![jenkins-slave-npm-build](../images/exercise2/jenkins-slave-npm-build.png)
300
301 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
302 <p class="tip">
303 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.
304 </p>
305
306 ### Part 3 - Add configs to cluster 
307 > _In this exercise; we will use the OpenShift Applier to drive the creation of cluster content required by the app such and MongoDB and the Apps Build / Deploy Config_
308
ea568d 309 4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move (cd .openshift-applier) into this directory and you should see a familiar looking directory structure for an ansible playbook. 
cdcafd 310 ```
D 311 .openshift-applier
312 ├── README.md
313 ├── apply.yml
314 ├── inventory
315 │   ├── group_vars
316 │   │   └── all.yml
317 │   └── hosts
318 ├── params
319 │   ├── build
320 │   ├── dev
321 │   └── test
322 ├── requirements.yml
323 └── templates
324     ├── todolist-api-build.yml
325     └── todolist-api-deploy.yml
326 ```
327 where the following
328     * the `apply.yml` file is the entrypoint.
329     * the `inventory` contains the objects to populate the cluster with.
330     * the `params` contains the variables we'll apply to the `templates`
331     * the `templates` required by the app. These include the Build, Deploy configs as well as the services, health checks and other app definitions.
332
333 4. There are a few updates to these manifests we need to make before applying the cluster content. In the `apply.yml` update the namespace `<YOUR_NAME>` variables accordingly.
334 ```yaml
335     ci_cd_namespace: donal-ci-cd
336     dev_namespace: donal-dev
337     test_namespace: donal-test
338 ```
339
c58300 340 4. In the `params` folder update the `dev` and `test` files with the correct `<YOUR_NAME>` as you've done above. Example for the `dev` file
cdcafd 341 ```bash
D 342 PIPELINES_NAMESPACE=donal-ci-cd
c58300 343 NAME=todolist-fe
cdcafd 344 DEPLOYER_USER=jenkins
D 345 APP_TAG=latest
346 NAMESPACE=donal-dev
347 ```
348
349 4. With those changes in place we can now run the playbook. First install the `openshift-applier` dependency and then run the playbook. This will populate the cluster with all the config needed for the front end app.
350 ```bash
351 $ ansible-galaxy install -r requirements.yml --roles-path=roles
352 $ ansible-playbook apply.yml -i inventory/
353 ```
071905 354 ![ansible-success](../images/exercise2/ansible-success.png)
cdcafd 355
ea568d 356 4. Back on your terminal navigate to the root of the `todolist-api` application. Open the `.openshift-applier` directory. The same layout of the frontend app should be visible with one noticeable difference; the api requires a `MongoDB` to connect to at runtime.
c58300 357
D 358 4. In the `apply.yml` update the namespace `<YOUR_NAME>` variables accordingly. For example:
359 ```yaml
360     ci_cd_namespace: donal-ci-cd
361     dev_namespace: donal-dev
362     test_namespace: donal-test
363 ```
364
365 4. In the `params` folder update the `dev` and `test` files with the correct `<YOUR_NAME>` as you've done above. Example for the `dev` file:
366 ```bash
367 PIPELINES_NAMESPACE=donal-ci-cd
368 NAME=todolist-api
369 DEPLOYER_USER=jenkins
370 APP_TAG=latest
371 NAMESPACE=donal-dev
372 ```
373
374 4. Finally; run the applier and install it's dependencies to run the content into the cluster
375 ```bash
376 $ ansible-galaxy install -r requirements.yml --roles-path=roles
377 $ ansible-playbook apply.yml -i inventory/
378 ```
9fc88c 379
D 380 ### Part 4 - Build > Bake > Deploy 
0e648a 381 > _In this exercise; we take what we have working locally and get it working in OpenShift_
9fc88c 382
41217d 383 This exercise will involve creating three stages (or items) in our pipeline, each of these is detailed below at a very high level. Move on to the next step to begin implementation.
D 384 * a *build* job is responsible for compiling and packaging our code:
385     1. Checkout from source code (`develop` for `<yourname>-dev` & `master` for `<yourname>-test`)
386     2. Install node dependencies and run a build / package
387     3. Send the package to Nexus
388     4. Archive the workspace to persist the workspace in case of failure
389     4. Tag the GitLab repository with the `${JOB_NAME}.${BUILD_NUMBER}` from Jenkins. This is our `${BUILD_TAG}` which will be used on downstream jobs.
390     5. Trigger the `bake` job with the `${BUILD_TAG}` param
391 * a *bake* job should take the package and put it in a Linux Container
392     1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`.
393     2. Checkout the binary from Nexus and unzip it's contents
394     3. Run an oc start-build of the App's BuildConfig and tag it's imagestream with the provided `${BUILD_TAG}`
395     4. Trigger a deploy job using the parameter `${BUILD_TAG}`
396 * a *deploy* job should roll out the changes by updating the image tag in the DC:
397     1. Take an input of the `${BUILD_TAG}`
398     2. Patch / set the DeploymentConfig to the image's `${BUILD_TAG}`
399     3. Rollout the changes
400     4. Verify the deployment
76d54e 401 * We will now go through these steps in detail.
9fc88c 402
41217d 403 #### Part 4a - Build
9fc88c 404
c58300 405 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. ![new-item](../images/exercise2/new-item.png)
9fc88c 406
579436 407 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>`. ![freestyle-job](../images/exercise2/freestyle-job.png)
9fc88c 408
579436 409 5. The page that loads is the Job Configuration page. It can be returned to at anytime from Jenkins. 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 ![keep-artifacts](../images/exercise2/keep-artifacts.png)
43f2f2 410
579436 411 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` ![label-jenkins-slave](../images/exercise2/label-jenkins-slave.png)
c951f7 412
579436 413 5. On the Source Code Management tab, specify the endpoint for our GitLab `todolist-fe` Project and specify your credentials from the dropdown box. Set the Branch Specifier to `develop`. ![git-scm](../images/exercise2/git-scm.png)
c951f7 414
579436 415 5. Scroll down to the Build Environment tab and select the `Color ANSI Console Output` checkbox ![ansi](../images/exercise2/ansi.png)
e919d0 416
76d54e 417 5. Move on to the Build section and select `Add build step`. From the dropdown select `Execute Shell`. On the box that appears; insert the following, to build package and deploy our app to Nexus:
e919d0 418 ```bash
D 419 #!/bin/bash
420 set -o xtrace
421 scl enable rh-nodejs8 'npm install'
422 scl enable rh-nodejs8 'npm run build:ci:dev'
423 scl enable rh-nodejs8 'npm run package'
424 scl enable rh-nodejs8 'npm run publish'
425 ```
426 ![build-step](../images/exercise2/build-step.png)
427
579436 428 5. Scroll to the final section; the Post-build Actions. Add a new post-build action from the dropdown called `Archive the artifacts` and specify `**` in the box. This will zip the entire workspace and copy it back to Jenkins for inspection if needed. ![archive-artifacts](../images/exercise2/archive-artifacts.png)
e919d0 429
579436 430 5. On the Post-build Actions; Add another post-build action from the dropdown called `Git Publisher`. This is useful for tying the git check-in to the feature in your tracking tool to the built product.
e919d0 431     * Tick the box `Push Only If Build Succeeds`
D 432     * Add the Tag to push of 
433 ```bash
434 ${JOB_NAME}.${BUILD_NUMBER}
435 ```
436     * Specify the commit message to be
437 ```bash
438 Automated commit by jenkins from ${JOB_NAME}.${BUILD_NUMBER}
439 ```
440 ![git-publisher](../images/exercise2/git-publisher.png)
441
579436 442 5. Finally; add the trigger for the next job in the pipeline. Add another post-build action from the dropdown called `Trigger parameterized build on other projects`. 
e919d0 443     * Set the project to build to be `dev-todolist-fe-bake` 
D 444     * Set the condition to be `Stable or unstable but not failed`. 
445     * Click Add Parameters dropdown and select Predefined parameters. 
446     * In the box, insert our BUILD_TAG as follows
447 ```bash
448 BUILD_TAG=${JOB_NAME}.${BUILD_NUMBER}
449 ```
450 ![param-trigger](../images/exercise2/param-trigger.png)
451 <p class="tip">
3b5f91 452     NOTE - Jenkins might say "No such project ‘dev-todolist-fe-bake’. Did you mean ...." at this point. Don't worry; it's because we have not created the next job yet.
e919d0 453 </p>
D 454
579436 455 5. Hit `save` which will take you to the job overview page - and that's it; our *build* phase is complete!
e919d0 456
41217d 457 #### Part 4b - Bake
D 458
579436 459 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`.
e919d0 460
579436 461 5. This job is will take in the BUILD_TAG from the previous one so check the `This project is parameterized` box on the General tab.
3b5f91 462     * Add string parameter type
D 463     * set the name to `BUILD_TAG`. This will be available to the job as an Enviroment Variable.
464     * You can set `dev-todolist-fe-build.` as the default value for ease when triggering manually.
465     * The description is not required but a handy one for reference would be `${JOB_NAME}.${BUILD_NUMBER} of previous build eg dev-todolist-fe-build.1232`
466 ![param-trigger-bake](../images/exercise2/param-trigger-bake.png)
c951f7 467
579436 468 5. This time set the `Restrict where this project can be run` label to `master`.
3b5f91 469 <p class="tip">
D 470     This the default node that jobs run on. We don't want jenkins to execute the *bake* on any other nodes if the `master` is busy so it is always safer to specify it here.
471 </p>
472
579436 473 5. There is no Git or SCM needed for this job so move down to the Build Environment and tick `Delete workspace before build starts`
3b5f91 474
579436 475 5. Scroll down to the Build Environment tab and select the `Color ANSI Console Output` checkbox ![delete-ansi](../images/exercise2/delete-ansi.png)
3b5f91 476
579436 477 5. Move on to the Build section and select `Add build step`. From the dropdown select `Execute Shell`. On the box the appears; insert the following, to pull the package from Nexus. We patch the BuildConfig with the Jenkins Tag to get traceablility from feature to source code to built item. Finally; the oc start-build command is run:
3b5f91 478 ```bash
D 479 #!/bin/bash
d00794 480 curl -v -f http://admin:admin123@${NEXUS_SERVICE_HOST}:${NEXUS_SERVICE_PORT}/repository/zip/com/redhat/todolist/${BUILD_TAG}/package-contents.zip -o package-contents.zip
3b5f91 481 unzip package-contents.zip
D 482 oc project <YOUR_NAME>-ci-cd # probs not needed
483 NAME=todolist-fe
484 oc patch bc ${NAME} -p "spec:
485    output:
486      to:
487        kind: ImageStreamTag
488        name: '${NAME}:${BUILD_TAG}'"
489 oc start-build ${NAME} --from-dir=package-contents/ --follow
490 ```
491 ![bake-step](../images/exercise2/bake-step.png)
492
579436 493 5. Finally; add the trigger for the next job in the pipeline. Add a post-build action from the dropdown called `Trigger parameterized build on other projects`.
3b5f91 494     * Set the project to build to be `dev-todolist-fe-deploy`
D 495     * Set the condition to be `Stable`.
496     * Click Add Parameters dropdown and select Current build parameters. This will pass the ${BUILD_TAG} to the downstream job which we will create next.
497     * In the box, insert our BUILD_TAG as follows
498 ![downstream-trigger-deploy](../images/exercise2/downstream-trigger-deploy.png)
499
579436 500 5. Hit save! That's our *bake* phase done! Finally; on to our *deploy*
3b5f91 501
41217d 502 #### Part 4c - Deploy
D 503
579436 504 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 and but scroll to the bottom and Copy from `dev-todolist-fe-bake`.
D 505 ![copy-from](../images/exercise2/copy-from.png)
506
507 5. The only two differences between the jobs is the Build Step and there are no Post Build Actions. First to the Build tab and add the following to the shell box. The process for running the deploy is to tag the image created previously for use in the `dev` project. Then update the DeploymentConfig to use the Jenkins Tag which kicked the process off. Once successful; the changes are rolled out
508 ```bash
509 #!/bin/bash
510 set -o xtrace
511 # VARS
512 PIPELINES_NAMESPACE=donal-ci-cd
513 NAMESPACE=donal-dev
514 NAME=todolist-fe
515 oc project ${NAMESPACE}
516 oc tag ${PIPELINES_NAMESPACE}/${NAME}:${BUILD_TAG} ${NAMESPACE}/${NAME}:${BUILD_TAG}
517 oc set env dc ${NAME} NODE_ENV=dev
518 oc set image dc/${NAME} ${NAME}=docker-registry.default.svc:5000/${NAMESPACE}/${NAME}:${BUILD_TAG}
519 oc rollout latest dc/${NAME}
520 ```
521 ![deploy-step](../images/exercise2/deploy-step.png)
522
523 5. Secondly, add another build step called `Verify OpenShift Deployment` include the following
524     * Set the Project to your `<YOUR_NAME>-dev`
525     * Set the DeploymentConfig to your app's name `todolist-fe`
526     * Set the replica count to `1`
527 ![verify-deployment](../images/exercise2/verify-deployment.png)
528
529 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!
530
41217d 531 #### Part 4d - Pipeline
D 532
533 5. With our Jenkins setup in place; now move to our `todolist-fe` app. Open in it your favourite editor and navigate to `src/config/dev.js`. Update `<YOUR_NAME>` accordingly. For example:
534 ![fe-dev-config](../images/exercise2/fe-dev-config.png)
535
536 5. Repeat this for `src/config/test.js` file. Once done; commit your chanages and push them to GitLab
537 ```bash
538 $ git add .
539 $ git commit -m "ADD config for api"
540 $ git push
541 ```
542
543 5. Back on Jenkins; can tie all the jobs in the pipeline together into a nice single view using the Build Pipeline view. Back on the Jenkins home screen Click the + beside the all tab on the top. Give the new view a sensible name like `dev-todolist-fe-pipeline`
579436 544 ![add-view](../images/exercise2/add-view.png). 
D 545
546 5. Set the Pipeline Flow's Inital Job to `dev-todolist-fe-build` and save.
547 ![pipeline-flow](../images/exercise2/pipeline-flow.png)
548
d00794 549 5. You should now see the pipeline view. Run the pipeline by hitting build (you can move onto the next part while it is running as it may take some time). 
579436 550 ![dev-pipeline-view](../images/exercise2/dev-pipeline-view.png)
D 551
552 ### Part 5 - Backend Pipeline
d00794 553 > In this exercise we will use the Jobs created for the `todolist-fe` as a template to create a pipeline for the `todolist-api` app
579436 554
d00794 555 6. On Jenkins home; create a new job for our backend build called `dev-todolist-api-build`. Use the Copy from section to copy all the configuration from the `dev-todolist-fe-build`.
D 556 ![copy-fe-build](../images/exercise2/copy-fe-build.png)
579436 557
d00794 558 6. When this has loaded; find and replace both occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are: 
D 559     * The GitLab project URL
560     * Projects to build on the Post Build Action
579436 561
5eb156 562 6. On the Build tab; remove the `:dev` from the `npm run build:ci:dev` so it just reads.
d00794 563 ```bash
D 564 scl enable rh-nodejs8 'npm run build:ci'
565 ```
5eb156 566  The rest of the instructions can be left as they are.
579436 567
d00794 568 6. Save the configuration for `dev-todolist-api-build`
579436 569
d00794 570 6. On Jenkins home; create a new job for our backend build called `dev-todolist-api-bake`. Use the Copy from section to copy all the configuration from the `dev-todolist-fe-bake` as you've just done.
D 571
572 6. When this has loaded; find and replace the occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are:
573     * The BUILD_TAG default value and description
574     * NAME in the execute shell step
575     * Projects to build on the Post Build Action
576
577 6. Save the configuration for `dev-todolist-api-build`
578
579 6. On Jenkins home; create a new job for our backend build called `dev-todolist-api-deploy`. Use the Copy from section to copy all the configuration from the `dev-todolist-fe-deploy` as you've just done.
580
581 6. When this has loaded; find and replace the occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are:
582     * The BUILD_TAG default value and description
583     * NAME in the execute shell step
584     * The name of the DeploymentConfig to validate in the Verify OpenShift Deployment
585
586 6. Save the configuration for `dev-todolist-api-build` and that's it for wiring together our `todolist-api` pipeline.
587  
5eb156 588 6. Before we kick off the build; check our front end app and see if it has deployed successfully. Check the deployment in OpenShift and load the url. If it has been a success we should see our dummyData. This is because there is not backend deployed.
d00794 589 ![no-backend-app](../images/exercise2/no-backend-app.png)
D 590
591 6. Run the `dev-todolist-api-build` to trigger the backend pipeline. When complete we should see the sample data has changed
592 ![with-backend-app](../images/exercise2/with-backend-app.png)
c951f7 593
43f2f2 594 _____
D 595
c951f7 596 ## Extension Tasks
cf415b 597 > _Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution available and are provided for additional scope._
c951f7 598
e919d0 599 - Git Tasks
D 600     * Add a GitHub Webhook to trigger your build on each commit
d00794 601 - Pipeline Tasks
D 602     * Add pipeline for <master> branch for each project.
603     * Use `test-` instead of `dev-` across all config and names
c58300 604     * Do the `.openshift-applier` steps as part of the pipeline.
e919d0 605 - Promote build
3b5f91 606     * Create a _promote-to-uat_ phase after the <master> branch deploy
cf415b 607     * Create a `uat` env using the OpenShift Applier as seen before
e919d0 608     * Tag and promote the image without rebuilding after the `test-**-deploy`
c58300 609 - MongoDB tasks
e919d0 610     * Add MongoDB Stateful set for the UAT environment (or test)
D 611     * Inject MongoDB config into the NodeJS app using config map & secrets.
cf415b 612     * Improve the security of the DB by making the user /passwords randomly generated
e919d0 613 - Setup Nexus as an `npm` mirror registry and use it in the builds to speed up the build time
c951f7 614
D 615 ## Additional Reading
43f2f2 616 > List of links or other reading that might be of use / reference for the exercise
D 617
7383de 618  -  What's in a package.json?
D 619
43f2f2 620 ## Slide links
399baa 621 > link back to the deck for the supporting material