# Lab 3 - CI Continuous Integration (CI) and Countinous Delivery (CD) are today standards for testing and delivering software. It is used for several times a day to integrate developer changes the system, which includes running unit tests to determine that the code works as you have thought. The goal is to ensure that there is always a version of the product that is ready to be delivered. In this laboration, you must set up a CI system using Gitlab-Ci.Gitlab-CI uses docker as underlying technology, therefore a certain understanding of docker is also required. Docker is an open-source project that automates the driving of applications inside _Containers_. A container contains everything needed for the application to run. This, in combination with the docker is immutable means that you can be able to run the code in the same environment regardless of platform. For higher grades you should also add a deployment step. ## Documentation ### GitLab-CI - [GitLab Continuous Integration](https://about.gitlab.com/product/continuous-integration/) - [GitLab CI getting started ](https://docs.gitlab.com/ee/ci/quick_start/) - [A movie that introduces GitLab-CI](https://www.youtube.com/watch?v=Jav4vbUrqII) ### Docker - Introducing the most important concepts within docker: [Getting started](https://docs.docker.com/get-started/) - Getting started - Linux: https://docs.docker.com/linux/ - OS X: https://docs.docker.com/mac/ - Windows: https://docs.docker.com/windows/ - Official documentation: https://docs.docker.com ### YAML - [Learn yaml in Y minutes](https://learnxinyminutes.com/docs/yaml/) ## Task The basic task consists of the following components: - GitLab project (gitlab.liu.se) - Source code for a project - gitlab-ci.yml file With the help of these components, create a system that allows the following Workflow: 1.A developer pushes to a Gitlab project/repository. 2. In response that there are new changes to Gitlab, Gilab-Ci automatically starts a pipeline and builds, tests, and starts/packing your application using the .gitlab-ci.yml file. .gitlab-ci.yml thus need to be in Gitlab Repot. 3. Notify the developers with the results of the tests, via e.g.email or slack. Which application to use is up to you to determine. If you have an old project (eg, candidate work) we recommend that you use it. The requirement for such a project is that it consists of parts that can be divided into different components. An example of this is a system with an application code with a database. If you do not have their own project that is suitable, we have a sample project that can be used: [git@gitlab.liu.se:large-scale-dev/ci-sample-project.git](git@gitlab.liu.se:large-scale-dev/ci-sample-project.git). The project's README.md describes what you need to know to build the project and run the tests. Here the go code, PostgreSQL and Nginx to run in three separate containers, but it is not a requirment for hte lab To handle several different images, it is recommended that you use Docker-compose. However, this is no requirement. ### Requirments - The workflow described above should be carried out. - There should be at least three different steps (Stages) in your pipline - There should be a BEFORE_Script that makes the steps that are common to all more than one of your steps (such as install packages or dyl) - At least one of your steps should save something that is used in the next step.(Eg, compiled binaries can be saved between build and run steps / stages.) ### Higher grades For higher grades, add another step in your pipeline. You should carry out a deployment to an external valfi service (such as Heroku, OpenShift, Google) Create another step to DEPLOY: A your project. ### Presenting your work The task is reported by recording a screencast where you explain the various aspects of your assembled CI system and show how it works as a whole. Thus: Demonstrate that when you create the push of a change, Gitlab-Ci runs your steps (for higher grades even deployment). Be sure to explain what is happening in every step.