What is CI/CD?
“Continuous integration focuses on blending the work products of individual developers together into a repository. Often, this is done several times each day, and the primary purpose is to enable early detection of integration bugs, which should eventually result in tighter cohesion and more development collaboration.”
“The aim of continuous delivery is to minimize the friction points that are inherent in the deployment or release processes. Typically, the implementation involves automating each of the steps for build deployments such that a safe code release can be done—ideally—at any moment in time. Continuous deployment is a higher degree of automation, in which a build/deployment occurs automatically whenever a major change is made to the code.”
Gitlab CI Agent is GitLab Continuous Integration & Deployment GitLab has integrated CI/CD pipelines to build, test, deploy, and monitor your code.
To successfully create a CI/CD pipeline using Gitlab you’ll need a couple of things :
1. Pipline on Gitlab
Create your CI/CD pipeline on Gitlab or a self hosted gitlab as well.
The pipeline,which is basically a set of instructions should be created in a file .gitlab-ci.yml placed in your project root. Check this to write your own but a simple pipeline would look something like this
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# These are the default stages.
# You don't need to explicitly define them.
# But you could define any stages you want.
stages:
- build
- test
- deploy
# This is the name of the job.
# You can choose it freely.
maven_build:
# A job is always executed within a stage.
# If no stage is set, it defaults to 'test'.
stage: test
# Since we require Maven for this job,
# we can restrict the job to runners with a certain tag.
# Of course, it is our duty to actually configure a runner
# with the tag 'maven' and a working maven installation
tags:
- maven
- java
- ubuntu
# Here you can execute arbitrate terminal commands.
# If any of the commands returns a non zero exit code the job fails.
script:
- echo "Maven build started"
- mvn verify
2. Setup Host server
Install mvn and the necessary dependencies to run your application. Then install the gitlab runner which is also available for platforms like Linux, MacOS, K8s and Windows.
If you’re too careful and would want to test if it works you can use Docker no need to pay for a new server.
i. Verify your installation
1
2
$ gitlab-runner list
Listing configured runners ConfigFile=/{HOME}/.gitlab-runner/config.toml
This is expected because we do not have nay configured pipelines
ii. Register a CI/CD pipeline
Register pipeline with :
1
gitlab-runner register
You’ll have to fill the prompt with the right parameters
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com/
Please enter the gitlab-ci token for this runner:
token1234
Please enter the gitlab-ci description for this runner:
[$]: maven-demo-app
Please enter the gitlab-ci tags for this runner (comma separated):
maven, java, ubuntu
Whether to run untagged builds [true/false]:
[false]:
Whether to lock Runner to current project [true/false]:
[false]: true
Registering runner... succeeded runner=random_Q3_i4
Please enter the executor: docker-ssh, parallels, ssh, docker+machine, docker-ssh+machine, docker, shell, virtualbox, kubernetes:
shell
Note:
gitlab-ci: 
gitlab-ci tags is a discrimintor with which we can tell the runner to either deploy the build or skip it. With this example the tags are maven, java, maven and by setting the runner not to run untagged builds we’ve essentially turn the discriminator on. We assigned the tag to our build in the .gitlab-ci.yml file with this :
1
2
tags:
- maven
Gitlab runner has different executors for running the build, the executor for the maven is shell.
You can also configure Gitlab to pass custom environment variables. I prefer not to do this though. Configurations are always managed by a configuration server.
iii. Running the Build
Now the Runner is ready we can test by pushing a commit to your GitLab. Gitlab automatically triggers the pipeline once the tags match.
Each commit is represent differently on Gitlab with test results as well details on whether it was deployed on target host. There’s also information on when it was executed
REFERENCES https://docs.gitlab.com/runner/