13 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](https://gitlab.com) provides an integrated CI/CD DevOps pipeline which makes use of Docker containers and is simple to configure.
2. [CodeShip](https://codeship.com) is example of Software as a Service (SaaS) and integrates with GitHub via an authentication token.

Resources:

1. [Lecture slides](https://drive.google.com/open?id=1b00JkdBlx05DjDrWKwZdJtzHbJR7Nstfw4_vUR9StBE)
2. [Starting and Scaling DevOps in the Enterprise (e-book)](https://page.gitlab.com/rs/194-VVC-221/images/Starting%20and%20Scaling%20DevOps%20in%20the%20Enterprise.pdf)
3. [Simple authentication API](https://gitlab.com/covcom/authentication)

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:

![GitHub settings](exercises/.images/codeship01.png)

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

![Token permissions](exercises/.images/codeship02.png)

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.

![Token permissions](exercises/.images/codeship03.png)

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

![Token permissions](exercises/.images/codeship04.png)

## 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!

![Token permissions](exercises/.images/codeship05.png)

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](https://gitlab.com/covcom/continuous-integration-example)

## 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](https://gitlab.com/covcom/continuous-integration-example) 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](https://hub.docker.com/r/jenkins/jenkins/) which you can deploy to a heroku instance.