05 Lab 2 Continuous Delivery.md

Continuous Delivery

In this lab you will learn how to implement Continuous Delivery of your application using two different services:

1. GitLab provides an integrated CI/CD DevOps pipeline which makes use of Docker containers and is simple to configure.
2. CodeShip is example of Software as a Service (SaaS) and integrates with GitHub via an authentication token.

Resources:

1. Lecture slides
2. Starting and Scaling DevOps in the Enterprise (e-book)
3. Simple authentication API

Feel free to make use of the simple authentication API in your assignment, this will allow you to focus on building the core functionality. Be aware you will need to modify it to get it to integrate into the rest of your project.

CodeShip CI

The first step you need to take is to authenticate CodeShip by creating an access token. From the top right menu choose settings:

Choose Developer settings from the left sidebar and then choose Personal access tokens.

Choose Generate new token. You will need to choose the following permissions:

1. admin:public_key
2. admin:repo_hook
3. repo

Call the new token CodeShip and generate the token. You will then need to copy this to the clipboard.

Log into CodeShip and locate the Connected services option from the settings menu.

Switch on the GitHub enterprise option and enter the following details, substituting your university username and your access token.

Adding a New Project

You should now access the Projects menu in CodeShip and choose New Project. Make sure you choose the GitHub Enterprise link and not the GitHub icon!

Paste in the GitHub url where requested and, on the next screen select Basic project.

On the Configure your tests screen choose NodeJS from the dropdown list and delete all the commands from the list except npm install.

---

Each week you will be expected to complete a series of lab activities. You will be required to reflect on these in your assignment so make sure you keep records of what you have done. This lab will include your third sprint and will bring together many of the topics already covered.

There is an example repository on GitLab

1 Configuring Continuous Delivery

In the previous sprint you used the Pull Request mechanism to integrate code into the master branch. In this sprint you will replace this with the process of Continuous Integration. These two approaches are non-complimentary and each has its pros and cons. By the end of this sprint you will have a good understanding of these.

Your team should already have a suite of tests for both functional and non-functional requirements for each component in your project and, in this lab, you will be using these to build a Continuous Delivery Pipeline using the tools integrated into GitLab.

The restrictions are that you can only use tests that return either pass or fail and have a non-zero code on failure. This should include:

1. Linters.
2. Unit tests.
3. Module dependency tests.
4. Code duplication checks.
5. Code coverage checks (if there is an option to specify thresholds).

You will need to create a .gitlab-ci.yml file in the root directory of your project which will be detected by GitLab and run each time you push your code. These are lots of examples available for you to learn from, both in the exercises/08_ci/ directory and online. Make sure the CI Pipeline is correctly configured by pushing both good and bad code before starting your third sprint.

You will also need to configure GitLab to only allow merging if all tests have passed. In this way you can bypass the requirement for the code to be reviewed by the Scrum Master which should speed up the process of integrating code into the Master branch.

1.1 Examples

To help you configure your GitLab CI pipeline there are a couple of sample repositories you should be studying which cover most of the platforms you are developing for:

ci-nodejs shows how to build a CI and CD pipeline for a NodeJS API.

2 Development Process

1. Create a local feature branch if the task is new and push to remote.
2. Rest of team pull the branch and switch to it then run existing test suites.
3. Write unit tests and integration tests to define new functionality.
4. Now code should be written to pass the tests making sure all the non-functional tests such as the linter and code duplication checker still pass.
5. Once local tests pass:
   1. code should be pushed to remote (triggering CI tests).
   2. Code changes should be pulled from the master branch.
6. Now the branch can be merged into the master branch:
   1. Create a pull request on GitLab.
   2. If all the tests have passed on both branches you can merge the code.
   3. Delete the feature branch if the feature is complete.

Jenkins

Docker Hub contains a complete Jenkins image which you can deploy to a heroku instance.