RedHatTraining/rht-labs-docs.git

Adapt documentation for the new name convention for Cluster API and Routes

Marcos Entenza

2018-11-22 530a252602df82868700d9d835ebdef3cdacbc20

commit \| author \| age
2b8436	1	# Attack of the Pipelines
c951f7	2
b5d705	3	> In this exercise we will explore the sample TODO List application and create a pipeline in Jenkins to build and deploy our code.
2b8436	4
D	5	![jenkins-time](../images/exercise2/jenkins-time.jpg)
	6
14cd2d	7	## Exercise Intro
e43fd2	8	This lesson is focused on creating a pipeline for our application. What is a pipeline? A pipeline is a series of steps or stages that takes our code from source to a deployed application. There can be many stages to a pipeline but a simple flow is to run a `build > bake > deploy`. Usually the first stage is triggered by something like a git commit. There could be many steps in each of these stages; such as compiling code, running tests and linting. All of these are done to try and drive up code quality and give more assurance that what is deployed is behaving as expected. In the exercise we will create Jenkins pipeline by configuring it through the UI, this will create an un-gated pathway to production
14cd2d	9
1173e5	10	First we will explore the sample application and get it running locally. The sample app is a `todolist` app - the `Hello World` app of the modern day.
14cd2d	11
D	12	#### Why create pipelines
	13	* Assurance - drive up code quality and remove the need for dedicated deployment / release management teams
	14	* Freedom - allow developers to take ownership of how and when code gets built and shipped
3f6da0	15	* Reliability - pipelines are a bit boring; they execute the same way each and every time they're run!
14cd2d	16	* A pathway to production:
D	17	- Puts the product in the hands of the customer quicker
	18	- Enables seamless and repeatable deploys
	19	- More prod like infrastructure increases assurance
	20	- “We have already done it” behavior de-risks go live
	21
43f2f2	22	_____
c951f7	23
D	24	## Learning Outcomes
2b8436	25	As a learner by the end of this lesson you will be able to
D	26
	27	- Build and run the full stack of the TODO List application locally
	28	- Create an un-gated pipeline using the Jenkins UI for the backend and frontend
	29	- Add branching to the pipeline to target specific namespace
c951f7	30
D	31	## Tools and Frameworks
cebd30	32	> The following tools are used throughout this exercise. Familiarity with them is not required but knowing what they are may help. You will not need to install Vue or Mongodb they are taken care of by our `todolist` app.
c951f7	33
D	34	1. [Jenkins](https://jenkins.io/) - OpenSource build automation server; highly customisable through plugins
2b8436	35	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	36	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
	37	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	38
43f2f2	39	## Big Picture
664135	40	> From the previous exercise; we created some supporting tooling needed by our app. Now we will introduce our Sample App and create a pipeline for it
D	41
	42	![big-picture](../images/big-picture/big-picture-2.jpg)
43f2f2	43
D	44	_____
c951f7	45
D	46	## 10,000 Ft View
2b8436	47	> _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	48
e43fd2	49	2. Import the projects into your gitlab instance. See the README of each for build instructions
43f2f2	50
2b8436	51	2. Deploy a `MongoDB` using the provided template to all project namespace.
D	52
1173e5	53	2. Create 2 pipelines with three stages (`build`, `bake`, `deploy`) in Jenkins for `develop` & `master` branches on the `todolist-fe` such that:
e919d0	54	* a `Build` job is responsible for compiling and packaging our code:
2b8436	55	1. Checkout from source code (`develop` for `<yourname>-dev` & `master` for `<yourname>-test`)
D	56	2. Install node dependencies and run a build / package
e919d0	57	3. Send the package to Nexus
D	58	4. Archive the workspace to persist the workspace in case of failure
	59	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.
	60	5. Trigger the `bake` job with the `${BUILD_TAG}` param
	61	* a `Bake` job should take the package and put it in a Linux Container
2b8436	62	1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`.
8894bf	63	2. Checkout the binary from Nexus and unzip its contents
W	64	3. Run an oc start-build of the App's BuildConfig and tag its imagestream with the provided `${BUILD_TAG}`
2b8436	65	4. Trigger a deploy job using the parameter `${BUILD_TAG}`
e919d0	66	* a `deploy` job should roll out the changes by updating the image tag in the DC:
2b8436	67	1. Take an input of the `${BUILD_TAG}`
D	68	2. Patch / set the DeploymentConfig to the image's `${BUILD_TAG}`
	69	3. Rollout the changes
	70	4. Verify the deployment
	71
	72	2. Repeat the above setup for the backend `todolist-fe`. TIP - use the copy config to speed things up!
	73
	74	2. Verify that both apps and the DB are talking to one another as expected.
c951f7	75
D	76	## Step by Step Instructions
7383de	77	> This is a fairly structured guide with references to exact filenames and sections of text to be added.
c951f7	78
f016b7	79	### Part 1 - Explore the Todo List App
7383de	80	> _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	81
d4f1fa	82	#### 1a Todolist-fe
4c8010	83
33c738	84	2. Git clone the `todolist-fe` project to somewhere sensible and checkout the `develop` branch using the following.
7383de	85	```bash
fad576	86	cd ~/innovation-labs
D	87	```
	88	```bash
b6978f	89	git clone https://github.com/rht-labs/todolist-fe.git
fad576	90	```
D	91	```bash
b6978f	92	cd todolist-fe
4c8010	93	```
b6978f	94	```bash
D	95	./git-pull-all.sh
fad576	96	```
D	97	```bash
	98	git checkout develop
c951f7	99	```
7383de	100
8894bf	101	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 its remote address. ![new-gitlab-proj](../images/exercise2/new-gitlab-proj.png)
7383de	102
D	103	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
	104	```bash
b6978f	105	git remote set-url origin <YOUR_GIT_LAB_PROJECT>
10416f	106	# verify the origin has been updated
b6978f	107	git remote -v
D	108	git push -u origin --all
c951f7	109	```
7383de	110
D	111	2. To get the app running locally; first check you've got node and npm installed
	112	```bash
b6978f	113	node -v
D	114	npm -v
7383de	115	```
1173e5	116	<p class="tip" >
7383de	117	NOTE - If you are missing these dependencies; install them with ease using the [Node Version Manager](https://github.com/creationix/nvm)
D	118	</p>
	119	![node-version](../images/exercise2/node-version.png)
	120
e43fd2	121	2. The `todolist-fe` has a package.json at the root of the project, this defines some configuration for the app including its dependencies, dev dependencies, scripts and other configuration. Install the app's dependencies
7383de	122	```bash
b6978f	123	npm install
7383de	124	```
D	125
abb0a5	126	2. The `todolist-fe` has some scripts defined in the package.json at the root of the project. A snippet of the npm scripts are shown below. To run any of these scripts run `npm run <SCRIPT_NAME>`. Let's start by serving our application
7383de	127	![npm-scripts](../images/exercise2/npm-scripts.png)
D	128	```bash
	129	npm run serve
	130	```
	131
10416f	132	2. This will take sometime to execute; but once done it should open the browser for you displaying the homepage of the `todolist-fe` app.
7383de	133	![todo-list-app](../images/exercise2/todo-list-app.png)
10416f	134	* Click 'Todo' at the top of the home page to get to the above page.
abb0a5	135	* The server hosting it live reloads; so if you make changes to your code base the app will live update
7383de	136	* The Data you see in the screen is dummy / stubbed data. This is served up when there is no backend connection found
D	137
abb0a5	138	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 no persistence layer. We will add one in the next part.
7383de	139
D	140	3. The structure of the `todolist-fe` is as follows.
	141	```bash
	142	todolist-fe
	143	├── jest.config.js
	144	├── jsconfig.json
	145	├── nightwatch.config.js
	146	├── node_modules
	147	├── package.json
	148	├── public
	149	│ ├── favicon.ico
	150	│ ├── img
	151	│ ├── index.html
	152	│ └── manifest.json
	153	├── src
	154	│ ├── App.vue
	155	│ ├── assets
	156	│ ├── components
10416f	157	│ │ └── *
7383de	158	│ ├── config
D	159	│ ├── main.js
	160	│ ├── registerServiceWorker.js
	161	│ ├── router.js
	162	│ ├── scss
	163	│ ├── services
	164	│ ├── store
10416f	165	│ │ └── *
7383de	166	│ └── views
10416f	167	│ └── *
7383de	168	├── tests
D	169	│ ├── e2e
	170	│ └── unit
	171	└── vue.config.js
	172	```
	173	where the following are the important things:
	174	* `./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.
	175	* `./node_modules` is where the dependencies are stored
b5d705	176	* `./test` contains our end-to-end tests and unit tests. More covered on these in later exercises.
10416f	177	* `./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
7383de	178	* `./src/store` is the `vuex` files for managing application state and backend connectivity
D	179	* `./src/views` is the view containers; which are responsible for loading components and managing their interactions.
	180	* the `./src/router.js` controls routing logic. In our case the app only has one real endpoint.
1173e5	181	* `./src/scss` contains custom SCSS used in the application.
7383de	182	* `./*.js` is mostly config files for running and managing the app and the tests
c951f7	183
33c738	184	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 and change `<YOUR_NAME>` accordingly in the below commands.
4c8010	185	```bash
18681b	186	export NEXUS_SERVICE_HOST=$(oc get route nexus --template='{{.spec.host}}' -n <YOUR_NAME>-ci-cd)
33c738	187	```
D	188	```bash
4c8010	189	export NEXUS_SERVICE_PORT=80
33c738	190	```
D	191	```bash
4c8010	192	npm run prepare-nexus
A	193	```
	194	<p class="tip">
	195	NOTE - This step in a residency would be automated by a more complex nexus deployment in the ci-cd project
	196	</p>
	197
d4f1fa	198	#### 1b Todolist-api
456daa	199
d2e708	200	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	201	```bash
fad576	202	cd ~/innovation-labs
D	203	```
	204	```bash
b6978f	205	git clone https://github.com/rht-labs/todolist-api.git
fad576	206	```
D	207	```bash
b6978f	208	cd todolist-api
4c8010	209	```
b6978f	210	```bash
D	211	./git-pull-all.sh
fad576	212	```
D	213	```bash
	214	git checkout develop
d2e708	215	```
D	216
8894bf	217	2. On GitLab; create a new project (internal) called `todolist-api` to host your clone of the project and copy its remote address as you did for the previous repositories.
d2e708	218
D	219	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
	220	```bash
b6978f	221	git remote set-url origin <YOUR_GIT_LAB_PROJECT>
D	222	```
	223	```bash
	224	git push -u origin --all
d2e708	225	```
D	226
	227	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
	228	```bash
b6978f	229	npm i
d2e708	230	```
D	231
	232	2. While the dependencies are being installed; explore the project structure.
	233	```bash
	234	todolist-api
	235	├── Dockerfile
	236	├── Gruntfile.js
	237	├── README.md
	238	├── node_modules
	239	├── package-lock.json
	240	├── package.json
	241	├── server
	242	│ ├── api
	243	│ │ └── todo
	244	│ ├── app.js
	245	│ ├── components
	246	│ │ └── errors
	247	│ ├── config
	248	│ │ ├── environment
	249	│ │ ├── express.js
	250	│ │ ├── local.env.sample.js
	251	│ │ └── seed.js
	252	│ ├── mocks
	253	│ │ ├── mock-routes-config.json
	254	│ │ ├── mock-routes.js
	255	│ │ └── mock-routes.spec.js
	256	│ ├── routes.js
	257	│ └── views
	258	│ └── 404.html
	259	└── tasks
	260	└── perf-test.js
	261	```
	262	where the following are the important things:
	263	* `./server` is the main collection of files needed by the app. The entrypoint is the `app.js`
	264	* `./node_modules` is where the dependencies are stored
1173e5	265	* `./server/api` is where the api's controller, data model & unit test are stored.
d2e708	266	* `./server/mocks` is a mock server used for when there is no DB access
10416f	267	* `./server/config` stores our Express JS config, header information and other middleware.
1173e5	268	* `./server/config/environment` stores environment specific config; such as connectivity to backend services like MongoDB.
b5d705	269	* `./tasks` is a collection of additional `Grunt` tasks which will be used in later exercises
10416f	270	* `Grunt` is a taskrunner for use with Node.JS projects
d2e708	271	* `package.json` contains the dependency list and a lot of very helpful scripts for managing the app lifecycle
D	272
df8dea	273	2. A snippet of 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.
d2e708	274	```json
D	275	"scripts": {
	276	"start": "node server/app.js",
	277	"dev": "./node_modules/.bin/grunt serve",
	278	"jshint": "./node_modules/.bin/grunt jshint",
	279	"clean": "rm -rf reports package-contents*",
	280	"package": "zip -r package-contents.zip package-contents",
	281	"test": "node_modules/.bin/nyc node_modules/.bin/mocha server/*/.spec.js --exit",
	282	"mongo" : "docker run -i -d --name mongo-local -p 27017:27017 mongo",
	283	"mongo:drop" : "npm run mongo:stop && docker rm mongo-local",
	284	"mongo:stop" : "docker stop mongo-local",
	285	"mongo:start" : "docker start mongo-local"
	286	},
456daa	287	```
A	288
e43fd2	289	2. To run the application; start a new instance of MongoDB by running the following. This will pull a mongodb image from Dockerhub and then start it for our API to connect to.
d2e708	290	```bash
b6978f	291	npm run mongo
d2e708	292	```
D	293	<p class="tip">
60ff08	294	NOTE - `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
d2e708	295	</p>
D	296
	297	2. Fire up the `todolist-api` by running.
	298	```bash
b6978f	299	npm run start
d2e708	300	```
D	301	![node-app-started](../images/exercise2/node-app-started.png)
	302
10416f	303	2. Check things are up and running by testing the API with a `curl`. The API should return some seeded data (stored in `server/config/seed.js`)
d2e708	304	```bash
b6978f	305	curl localhost:9000/api/todos
d2e708	306	```
D	307	```json
	308	[{
	309	"_id": "5ac8ff1fdfafb02138698948",
	310	"title": "Learn some stuff about MongoDB",
	311	"completed": false,
	312	"__v": 0
	313	},
	314	{
	315	"_id": "5ac8ff1fdfafb02138698949",
	316	"title": "Play with NodeJS",
	317	"completed": true,
	318	"__v": 0
	319	}]
	320	```
	321
10416f	322	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. Adding new todos will add them in the backend, these will persist when the page is refreshed.
d2e708	323	![fullstack-app](../images/exercise2/fullstack-app.png)
D	324
1173e5	325	### Part 2 - Add configs to cluster
f016b7	326	> _In this exercise; we will use the OpenShift Applier to drive the creation of cluster content required by the app such as MongoDB and the Apps Build / Deploy Config_
9fc88c	327
1173e5	328	4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move into this `.openshift-applier` directory and you should see a familiar looking directory structure for an Ansible playbook.
cdcafd	329	```
D	330	.openshift-applier
	331	├── README.md
	332	├── apply.yml
	333	├── inventory
	334	│ ├── group_vars
	335	│ │ └── all.yml
	336	│ └── hosts
	337	├── params
	338	│ ├── build
	339	│ ├── dev
68d81a	340	│ ├── ocp-pipeline
cdcafd	341	│ └── test
D	342	├── requirements.yml
	343	└── templates
68d81a	344	├── ocp-pipeline.yml
D	345	├── todolist-fe-build.yml
	346	└── todolist-fe-deploy.yml
cdcafd	347	```
ea5b30	348	with the following
1173e5	349	* the `apply.yml` file is the entrypoint.
cdcafd	350	* the `inventory` contains the objects to populate the cluster with.
D	351	* the `params` contains the variables we'll apply to the `templates`
f016b7	352	* the `templates` required by the app. These include the Build, Deploy configs as well as the services, health checks, and other app definitions.
cdcafd	353
1173e5	354	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.
cdcafd	355	```yaml
D	356	ci_cd_namespace: donal-ci-cd
	357	dev_namespace: donal-dev
	358	test_namespace: donal-test
	359	```
	360
1173e5	361	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	362	```bash
D	363	PIPELINES_NAMESPACE=donal-ci-cd
c58300	364	NAME=todolist-fe
cdcafd	365	DEPLOYER_USER=jenkins
D	366	APP_TAG=latest
	367	NAMESPACE=donal-dev
	368	```
	369
f016b7	370	4. With those changes in place we can now run the playbook. First install the `openshift-applier` dependency and then run the playbook (from the `.openshift-applier` directory). This will populate the cluster with all the config needed for the front end app.
cdcafd	371	```bash
b6978f	372	ansible-galaxy install -r requirements.yml --roles-path=roles
D	373	```
	374	```bash
	375	ansible-playbook apply.yml -i inventory/
cdcafd	376	```
071905	377	![ansible-success](../images/exercise2/ansible-success.png)
cdcafd	378
f016b7	379	4. Once successful, `commit` and `push` your changes to gitlab.
68d81a	380	```bash
b6978f	381	git add .
D	382	```
	383	```bash
	384	git commit -m "UPDATE - change namespace vars to donal"
	385	```
	386	```bash
	387	git push
68d81a	388	```
f016b7	389
33c738	390	4. Back on your terminal navigate to the root of the `todolist-api` application. Open the `.openshift-applier` directory in your editor. The same layout as seen in `todolist-fe` should be visible with one noticeable difference; the api requires `MongoDB` to connect to at runtime.
c58300	391
D	392	4. In the `apply.yml` update the namespace `<YOUR_NAME>` variables accordingly. For example:
	393	```yaml
	394	ci_cd_namespace: donal-ci-cd
	395	dev_namespace: donal-dev
	396	test_namespace: donal-test
	397	```
	398
	399	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:
	400	```bash
	401	PIPELINES_NAMESPACE=donal-ci-cd
	402	NAME=todolist-api
	403	DEPLOYER_USER=jenkins
	404	APP_TAG=latest
	405	NAMESPACE=donal-dev
	406	```
	407
bfd54c	408	4. Finally; run the Openshift Applier and install its dependencies to run the content into the cluster
c58300	409	```bash
b6978f	410	ansible-galaxy install -r requirements.yml --roles-path=roles
D	411	```
	412	```bash
	413	ansible-playbook apply.yml -i inventory/
c58300	414	```
9fc88c	415
68d81a	416	4. Once successful, `commit` and `push` your changes to gitlab.
D	417	```bash
b6978f	418	git add .
D	419	```
	420	```bash
	421	git commit -m "UPDATE - change namespace vars to donal"
	422	```
	423	```bash
	424	git push
68d81a	425	```
e90e9c	426
68d81a	427	4. Validate the build and deploy configs have been created in Openshift by checking `<YOUR_NAME> CI-CD builds` for the `BuildConfigs`
D	428	![ocp-app-bc](../images/exercise2/ocp-app-bc.png)
	429
	430	4. Check `<YOUR_NAME>-dev` to see the deployment configs are in place
6c8424	431	![ocp-app-dc](../images/exercise2/ocp-app-dc.png)
e90e9c	432
1173e5	433	### Part 3 - Build > Bake > Deploy
0e648a	434	> _In this exercise; we take what we have working locally and get it working in OpenShift_
9fc88c	435
41217d	436	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	437	* a build job is responsible for compiling and packaging our code:
	438	1. Checkout from source code (`develop` for `<yourname>-dev` & `master` for `<yourname>-test`)
	439	2. Install node dependencies and run a build / package
	440	3. Send the package to Nexus
	441	4. Archive the workspace to persist the workspace in case of failure
	442	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.
	443	5. Trigger the `bake` job with the `${BUILD_TAG}` param
	444	* a bake job should take the package and put it in a Linux Container
	445	1. Take an input of the previous jobs `${BUILD_TAG}` ie `${JOB_NAME}.${BUILD_NUMBER}`.
8894bf	446	2. Checkout the binary from Nexus and unzip its contents
W	447	3. Run an oc start-build of the App's BuildConfig and tag its imagestream with the provided `${BUILD_TAG}`
41217d	448	4. Trigger a deploy job using the parameter `${BUILD_TAG}`
D	449	* a deploy job should roll out the changes by updating the image tag in the DC:
	450	1. Take an input of the `${BUILD_TAG}`
	451	2. Patch / set the DeploymentConfig to the image's `${BUILD_TAG}`
	452	3. Rollout the changes
	453	4. Verify the deployment
76d54e	454	* We will now go through these steps in detail.
9fc88c	455
5b1604	456	#### 3a - Build
9fc88c	457
c58300	458	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	459
40c0ca	460	5. Name this job `dev-todolist-fe-build` and select `Freestyle Project`. All our jobs will take the form of `<ENV>-<APP_NAME>-<JOB_PURPOSE>`. ![freestyle-job](../images/exercise2/freestyle-job.png)
9fc88c	461
e43fd2	462	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 build's artifacts. Tick the `Discard old builds` checkbox, then `Advanced` and set `Max # of builds to keep with artifacts` to 1 as indicated below
b815cc	463	![keep-artifacts](../images/exercise2/keep-artifacts.png)
43f2f2	464
5b1604	465	5. Our NodeJS build needs to be run on the `jenkins-slave-npm` we bought in in the previous chapter. Specify this in the box labelled `Restrict where this project can be run` ![label-jenkins-slave](../images/exercise2/label-jenkins-slave.png)
c951f7	466
1b285d	467	5. On the Source Code Management tab, select the Git radio button, 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	468
579436	469	5. Scroll down to the Build Environment tab and select the `Color ANSI Console Output` checkbox ![ansi](../images/exercise2/ansi.png)
e919d0	470
76d54e	471	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	472	```bash
D	473	set -o xtrace
4acca2	474	npm install
D	475	npm run build:ci:dev
	476	npm run package
	477	npm run publish
e919d0	478	```
D	479	![build-step](../images/exercise2/build-step.png)
	480
579436	481	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	482
579436	483	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	484	* Tick the box `Push Only If Build Succeeds`
1173e5	485	* Add the Tag to push of
e919d0	486	```bash
D	487	${JOB_NAME}.${BUILD_NUMBER}
	488	```
	489	* Specify the commit message to be
	490	```bash
	491	Automated commit by jenkins from ${JOB_NAME}.${BUILD_NUMBER}
	492	```
1b285d	493
A	494	* Check `Create New Tag` and set `Target remote name` to `origin`
e919d0	495	![git-publisher](../images/exercise2/git-publisher.png)
D	496
1173e5	497	5. Finally; add the trigger for the next job in the pipeline. This is to trigger the bake job with the current build tag. Add another post-build action from the dropdown called `Trigger parameterized build on other projects`.
CM	498	* Set the project to build to be `dev-todolist-fe-bake`
	499	* Set the condition to be `Stable or unstable but not failed`.
	500	* Click Add Parameters dropdown and select Predefined parameters.
e919d0	501	* In the box, insert our BUILD_TAG as follows
D	502	```bash
	503	BUILD_TAG=${JOB_NAME}.${BUILD_NUMBER}
	504	```
	505	![param-trigger](../images/exercise2/param-trigger.png)
	506	<p class="tip">
3b5f91	507	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	508	</p>
D	509
579436	510	5. Hit `save` which will take you to the job overview page - and that's it; our build phase is complete!
e919d0	511
5b1604	512	#### 3b - Bake
41217d	513
579436	514	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	515
1b285d	516	5. This job will take in the BUILD_TAG from the previous one so check the `This project is parameterized` box on the General tab.
3b5f91	517	* Add string parameter type
1b285d	518	* set the Name to `BUILD_TAG`. This will be available to the job as an Enviroment Variable.
3b5f91	519	* You can set `dev-todolist-fe-build.` as the default value for ease when triggering manually.
1173e5	520	* The description is not required but a handy one for reference would be `${JOB_NAME}.${BUILD_NUMBER} of previous build e.g. dev-todolist-fe-build.1232`
2ff842	521	<p class="tip">
A	522	NOTE - Don't forget to include the `.` after `dev-todolist-fe-build` in the Default Value box.
	523	</p>
	524
3b5f91	525	![param-trigger-bake](../images/exercise2/param-trigger-bake.png)
c951f7	526
579436	527	5. This time set the `Restrict where this project can be run` label to `master`.
3b5f91	528	<p class="tip">
2ff842	529	NOTE - `Master` is 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.
3b5f91	530	</p>
D	531
579436	532	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	533
579436	534	5. Scroll down to the Build Environment tab and select the `Color ANSI Console Output` checkbox ![delete-ansi](../images/exercise2/delete-ansi.png)
3b5f91	535
579436	536	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:
1b285d	537	Remember to replace `<YOUR_NAME>` accordingly.
3b5f91	538	```bash
D	539	#!/bin/bash
15b8f6	540	curl -v -f \
D	541	http://admin:admin123@${NEXUS_SERVICE_HOST}:${NEXUS_SERVICE_PORT}/repository/zip/com/redhat/todolist/${BUILD_TAG}/package-contents.zip \
	542	-o package-contents.zip
3b5f91	543	unzip package-contents.zip
cebd30	544	oc project <YOUR_NAME>-ci-cd
3b5f91	545	NAME=todolist-fe
9adaf7	546	oc patch bc ${NAME} -p "{\"spec\":{\"output\":{\"to\":{\"kind\":\"ImageStreamTag\",\"name\":\"${NAME}:${BUILD_TAG}\"}}}}"
3b5f91	547	oc start-build ${NAME} --from-dir=package-contents/ --follow
D	548	```
	549	![bake-step](../images/exercise2/bake-step.png)
	550
579436	551	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	552	* Set the project to build to be `dev-todolist-fe-deploy`
D	553	* Set the condition to be `Stable`.
3dce53	554	* Click Add Parameters dropdown and select `Current build parameters`. This will pass the `${BUILD_TAG}` to the downstream job which we will create next.
3b5f91	555	![downstream-trigger-deploy](../images/exercise2/downstream-trigger-deploy.png)
D	556
579436	557	5. Hit save! That's our bake phase done! Finally; on to our deploy
3b5f91	558
5b1604	559	#### 3c - Deploy
41217d	560
1b285d	561	5. Next we will setup our deploy phase. This job is very similar in setup to the bake phase so this time go to Jenkins home and create `dev-todolist-fe-deploy` Job but scroll to the bottom and Copy from `dev-todolist-fe-bake`.
579436	562	![copy-from](../images/exercise2/copy-from.png)
D	563
1b285d	564	5. The only two differences between these 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 `ci-cd` namespace 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. Remember to change `<YOUR_NAME>` accordingly.
579436	565	```bash
D	566	#!/bin/bash
	567	set -o xtrace
	568	# VARS
1b285d	569	PIPELINES_NAMESPACE=<YOUR_NAME>-ci-cd
A	570	NAMESPACE=<YOUR_NAME>-dev
579436	571	NAME=todolist-fe
D	572	oc project ${NAMESPACE}
	573	oc tag ${PIPELINES_NAMESPACE}/${NAME}:${BUILD_TAG} ${NAMESPACE}/${NAME}:${BUILD_TAG}
	574	oc set env dc ${NAME} NODE_ENV=dev
	575	oc set image dc/${NAME} ${NAME}=docker-registry.default.svc:5000/${NAMESPACE}/${NAME}:${BUILD_TAG}
	576	oc rollout latest dc/${NAME}
	577	```
	578	![deploy-step](../images/exercise2/deploy-step.png)
	579
8894bf	580	5. When a deployment has completed; OpenShift can verify its success. Add another step by clicking the `Add build Step` on the Build tab then `Verify OpenShift Deployment` including the following:
579436	581	* Set the Project to your `<YOUR_NAME>-dev`
D	582	* Set the DeploymentConfig to your app's name `todolist-fe`
	583	* Set the replica count to `1`
	584	![verify-deployment](../images/exercise2/verify-deployment.png)
	585
	586	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!
	587
5b1604	588	#### 3d - Pipeline
41217d	589
3dce53	590	5. With our Jenkins setup in place; now move to our `todolist-fe` app's source code. We have to add our configuration to the frontend to tell it where the API layer will be hosted. Open the source in your favourite editor and navigate to `src/config/dev.js`.
D	591
33c738	592	5. Update `<YOUR_NAME>` accordingly with the route where the Todo List API will live when it is deployed. The correct full URL can also be found on the OpenShift Console; if you copy it from there remember to append `/api/todos` to the URL. For example:
41217d	593	![fe-dev-config](../images/exercise2/fe-dev-config.png)
D	594
1173e5	595	5. Repeat this for `src/config/test.js` file. If you copy the URL from the previous step; change `dev` to `test`.
33c738	596	For example:
D	597	![fe-test-config](../images/exercise2/fe-test-config.png)
	598
a25623	599	5. With the config in place; commit your changes and push them to GitLab:
41217d	600	```bash
b6978f	601	git add .
D	602	```
	603	```bash
	604	git commit -m "ADD config for api"
	605	```
	606	```bash
	607	git push
41217d	608	```
D	609
cebd30	610	5. Back on Jenkins; We 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.
D	611	![add-view](../images/exercise2/add-view.png)
	612
e43fd2	613	5. On the view that loads; Give the new view a sensible name like `dev-todolist-fe-pipeline` and select Build Pipeline View
cebd30	614	![new-pipeline](../images/exercise2/new-pipeline.png)
579436	615
D	616	5. Set the Pipeline Flow's Inital Job to `dev-todolist-fe-build` and save.
	617	![pipeline-flow](../images/exercise2/pipeline-flow.png)
	618
cebd30	619	5. You should now see the pipeline view. Run the pipeline by hitting run (you can move onto the next part while it is running as it may take some time).
af284d	620	![dev-pipeline-view](../images/exercise2/dev-pipeline-view.jpeg)
579436	621
15b8f6	622	6. To check the deployment in OpenShift; open the web console and go to your `dev` namespace. You should see the deployment was successful; hit the URL to open the app (the screenshot below has both apps deployed).
cebd30	623	![ocp-deployment](../images/exercise2/ocp-deployment.png)
D	624
15b8f6	625	6. If it has been a success we should see our dummyData. This is because there is no backend deployed, in later labs we will deploy the backend and the mongodb for persistence but to do this we will use Jenkins Pipeline as code.
d00794	626	![no-backend-app](../images/exercise2/no-backend-app.png)
c951f7	627
5b1604	628	### Part 4 - (Optional) GitLab Webhooks
b00f5a	629	> _In this exercise we will link GitLab to Jenkins so that new build jobs are triggered on each push to the `develop` branch._
11b338	630
b00f5a	631	<p class="tip" >
943e9f	632	NOTE - This section is optional! Git webhooks are useful but not needed for Enablement completion.
b00f5a	633	</p>
D	634
530a25	635	7. In order to allow GitLab to trigger Jenkins (because of the OpenShift Auth Plugin), we need to allow the `Anonymous` user triggered 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_URL>/configureSecurity/` . You should see a screen like so:
106095	636	![jenkins-global-security](../images/exercise2/jenkins-global-security.png)
A	637
	638	7. Scroll down to the `Authorization` section and allow `Anonymous` to create jobs. Do this by navigating through the matrix of checkboxes and check `Build` and `Cancel` under the Job heading. Leave all other user behaviour as is. Anonymous is the user that GitLab will act as so this allows the WebHook to trigger builds. (The screenshot has been cropped to bring Job further to the left.) Hit `Save` or `Apply`.
	639	![jenkins-anon-permissions](../images/exercise2/jenkins-anon-permissions.png)
	640
530a25	641	7. Go to your `dev-todolist-fe-build` and head to the `configure` section (`https://jenkins-<YOUR_NAME>-ci-cd.<APPS_URL>/job/dev-todolist-fe-build/configure`). Scroll down to the `Build Triggers` section and check the `Build when a change is pushed to GitLab` box. Leave all the other settings as they are but copy the `GitLab webhook URL`. `https://jenkins-<YOUR_NAME>-ci-cd.<APPS_URL>/project/dev-todolist-fe-build`. Remember to Save and Apply this change.
0c725b	642	![jenkins-build-triggers-gitlab](../images/exercise2/jenkins-build-triggers-gitlab.png)
11b338	643
530a25	644	7. Switch over to GitLab and select your `todolist-fe` repository. On the left hand task bar hover over the settings cog and select `integrations`. (`https://gitlab-<YOUR_NAME>-ci-cd.<APPS_URL>/<YOUR_NAME>/todolist-fe/settings/integrations`)
0c725b	645	![gitlab-integrations](../images/exercise2/gitlab-integrations.png)
11b338	646
0c725b	647	7. Paste the `GitLab webhook URL` that we copied earlier into the `URL` field. Check Push events as the trigger, and make sure you `uncheck` the `SSL verification` checkbox. Click Add webhook at the bottom.
A	648	![gitlab-integrations-details](../images/exercise2/gitlab-integrations-details.png)
11b338	649
0c725b	650	7. Before we move on let's test the webhook. Select the Test drop down and click `Push events`. This will trigger the test and return a status code at the top of the page. If all goes well it should be a cool blue 200.
A	651	![gitlab-integrations-details](../images/exercise2/gitlab-webhook-test.png)
11b338	652
0c725b	653	7. We can now test this properly by heading into the `todolist-fe` repository through <YOUR_FAVOURITE_EDITOR>. Make a small change to your code, then commit and push it, ensuring you're on the develop branch. Then head over to Jenkins and wait until the `dev-todolist-fe-build` job has been triggered.
11b338	654
0c725b	655	7. We now have a working GitLab webhook so any time we push code it will automatically build! Next up we'll show you how to add tests to your pipeline.
b00f5a	656
43f2f2	657	_____
D	658
c951f7	659	## Extension Tasks
cf415b	660	> _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	661
d00794	662	- Pipeline Tasks
456daa	663	* Add pipeline for `master` branch for each project. Use `test-` instead of `dev-` across all config and names in the pipeline
A	664	* Do the `.openshift-applier` steps as part of the pipeline for greater end to end automation.
e919d0	665	- Promote build
456daa	666	* Create a _promote-to-uat_ phase after the `master` branch deploy
cf415b	667	* Create a `uat` env using the OpenShift Applier as seen before
e919d0	668	* Tag and promote the image without rebuilding after the `test-**-deploy`
c58300	669	- MongoDB tasks
e919d0	670	* Add MongoDB Stateful set for the UAT environment (or test)
D	671	* Inject MongoDB config into the NodeJS app using config map & secrets.
cf415b	672	* Improve the security of the DB by making the user /passwords randomly generated
e919d0	673	- Setup Nexus as an `npm` mirror registry and use it in the builds to speed up the build time
c951f7	674
D	675	## Additional Reading
43f2f2	676	> List of links or other reading that might be of use / reference for the exercise
7383de	677
43f2f2	678	## Slide links
7c832b	679
01c4da	680	- [Intro](https://docs.google.com/presentation/d/1t1CONuy-_IRPZYmU010Qgk2rshiDJTennvLyQR8GllE)
RH	681	- [Wrap-up](https://docs.google.com/presentation/d/1kZ8SV6iJnrKk_AqPpyPuNZifv7VzItHOB9HYdOnNJjI)
5d4563	682	- [All Material](https://drive.google.com/drive/folders/1lf66ks2tT0eQ4A9RSU48u0ZhvBXzoHWJ)