Module III

Continuous Integration and

Continuous Delivery
This chapter covers the following topics:
• CI/CD principles
• Using a package manager in the CI/CD process
• Using Jenkins for CI/CD implementation
• Using Azure Pipelines for CI/CD
• Using GitLab CI
Technical requirements
The only requirement for this chapter is to have Git installed on your system, as detailed
in the previous chapter.
CI/CD principles
• The setting up of a Git-type source control version (SCV) is a necessary prerequisite that

makes it possible to centralize the code of all the members of a team.

• The team will have to decide on a code branch that will be used for CI.
• In addition, CI is achieved by an automatic task suite that is executed on a server,

following similar patterns executed on a developer's laptop that has the necessary tools for
CI; this server is called the CI server.
• The CI server can be either of the on-premises type, installed in the company data center,

such as Jenkins or TeamCity,

To be able to host this package, we need a package manager, also called a repository
manager, which can be on-premises (installed locally) such as Nexus, Artifactory, or
ProGet, or a software-as-a-service (SaaS) solution such as Azure Pipelines, Azure
Artifacts, or the GitHub Packages registry.
CD
Once the application has been packaged and stored in a package manager during CI, the
CD process is ready to retrieve the package and deploy it in different environments.
During the deployment phase, it is often necessary to modify the configuration of
the application in the generated package in order for it to be adapted to the target
environment. It is, therefore, necessary to integrate a configuration manager that is
already present in common CI/CD tools such as Jenkins, Azure Pipelines, or Octopus
Deploy.
Using Jenkins for CI/CD implementation

Jenkins has become famous thanks to the large community working on it and its plugins.
Indeed, there are more than 1,500 Jenkins plugins that allow you to perform all types of
actions within your jobs. And if, despite everything, one of your tasks does not have a
plugin, you can create one yourself.
Installing and configuring Jenkins

1. To get all the steps to create an Azure VM with Jenkins already installed, read the
documentation available here: https://docs.microsoft.com/en-us/
azure/jenkins/install-jenkins-solution-template.
Once installed and created, we will access Jenkins in the browser by providing its
Uniform Resource Locator (URL) in the Azure portal in the DNS name field, as
shown in the following screenshot:
3. Follow the displayed instructions on the Jenkins home page to enable access to
this Jenkins instance via secure Secure Sockets Layer (SSL) tunneling.
4. Then, follow the configuration instructions on the Unlock Jenkins message
displayed on the Jenkins screen. Once the configuration is complete, we get Jenkins
ready to create a CI job.
Configuring a GitHub
webhook
In order for Jenkins to run a new job, we must first create a
webhook in the GitHub
repository. This webhook will be used to notify Jenkins as
soon as a new push occurs in
the repository.

• 1. In the GitHub repository, go to the Settings |

Webhooks menu.
• 2. Click on the Add Webhook button.
Webhooks

3. In the Payload URL field, fill in the URL address of

Jenkins followed by /githubwebhook/,
leave the secret input as it is, and choose the Just the push
event
option.
4. Validate the webhook.
 5. Finally, we can check on the GitHub
Webhooks interface that the webhook is well configured
and that it communicates with Jenkins.
Using GitLab CI

GitLab CI is one of the services offered by GitLab

(https://about.gitlab.com/),
which, like Azure DevOps, is a cloud platform with the following
attributes:
• A source code manager
• A CI/CD pipeline manager
• A board for project management
The other services it offers are listed here: https://about.gitlab.com/
features/.
Authentication at GitLab

Creating a GitLab account is free and can be done either by

creating a GitLab account or
using external accounts, such as Google, GitHub, Twitter,
or Bitbucket.
To create a GitLab account, we need to go to
https://gitlab.com/users/sign_
in#register-pane and choose the type of authentication.
GitLab
Registration
Gitlab Home page
Creating a new project
and managing your
source code
Click on Create a project on the home
page, as illustrated in the following
screenshot:
To create an empty project
(without code), the form
asks you to enter the
project's
name, as illustrated in the
following screenshot:
To create a new
project from a
built-in template
project, proceed
as follows:
To import code from an internal or external repository of
another SVC platform,
this is as shown in the following screenshot:
The code to import is located in an external SVC repository, as shown in
the
following screenshot:
GitLab

2. Once the project is created, we'll have a page that indicates the different Git
commands to execute to push its code.
3. To do this, on our local disk, we will create a new gitlab-ci-demo.yml file and
then copy the content of our example, which can be found at https://github.
com/PacktPublishing/Learning-DevOps-Second-Edition/tree/
main/CHAP07, in the gitlab-ci-demo.yml file.
4. Then, we will execute the following commands in a terminal to push the code into
the repository
GitLab

• git init
• git remote add origin <git repo Url>
• git add .
• git commit -m "Initial commit"
• git push -u origin master
Once these
commands have
been executed,
we'll obtain a
remote GitLab
repository with
our lab code
Creating a CI pipeline

In GitLab CI, the creation of a CI pipeline (and CD) is not

done via a graphical UI (GUI),
but with a YAML file at the root of the project.
This method, which consists of describing the process of a
pipeline in a file that is located
with the code, can be called Pipeline as Code (PaC), in the
same way as Infrastructure as
Code (IaC).
image: microsoft/dotnet:latest
stages:
- build
- test
variables:
BuildConfiguration: "Release"
build:
stage: build
script:
- "cd app"
- "dotnet restore"
- "dotnet build --configuration
$BuildConfiguration"
test:
stage: test
script:
- "cd tests"
- "dotnet test --configuration
$BuildConfiguration"
Creating a CI pipeline

We can see at the beginning of this code that we use a microsoft/

dotnet:latest Docker image that will be mounted in a container and in which
the actions of the pipeline will be executed.
Then, we define two stages, one for the build and one for the test execution, as well
as a BuildConfiguration variable that will be used in the scripts.
Finally, we describe each of the stages of the scripts to be executed in their
respective directories. These .NET core scripts are identical to the ones we saw
in the Using Azure Pipelines for CI/CD section.
2. Then, we will commit and push this file into the remote
repository.
3. Just after pushing the code, we can see that the CI process has
been triggered.
Accessing the CI 1. In the GitLab CI menu, go to CI / CD |
Pipelines, and you will see a list of pipeline
pipeline executions, as shown in the following screenshot:
execution details
2. To display the
details of the
pipeline, we click
on the desired
pipeline execution,
3. We can see the execution status, as well as the two stages that you defined in the
pipeline YAML file. To view the details of the execution logs for a stage, we click on
the stage.