An Overview

Created By:
Sheik Benazir Ahmed

GitLab CI/CD
(All contents are taken
from Gitlab’s official
documentation.)
Continuous Integration/Delivery/Deployment

Continuous Integration
• You can create a set of scripts to build and test your application automatically, for every push to the repository.
• This practice is known as Continuous Integration.
• These scripts help decrease the chances that you introduce errors in your application.
Continuous Delivery
• Step beyond Continuous Integration.
• Each time a code change is pushed to the codebase, the application is also deployed continuously.
• It requires human intervention to manually and strategically trigger the deployment of the changes.
Continuous Deployment
• Same as continuous delivery with one difference:
• Instead of deploying your application manually, you set it to be deployed automatically.
• Human intervention is not required
 • Contents:
Get Started: • CI/CD process overview
• Creating a sample “.gitlab-ci.yml” file
• View the status of your pipeline and jobs
• CI/CD Concepts
• Enable or Disable CI/CD
 • To use GitLab CI/CD:
• Ensure you have runners available to run your
jobs.
• If you don’t have a runner:
• Install GitLab Runner and register a
Get Started: CI/CD runner for your instance, project, or
group.
process overview • Create a “.gitlab-ci.yml” file at the root of your
repository.
• This file is where you define your CI/CD
jobs.
Get Started: Creating a sample “.gitlab-ci.yml” file

• You configure specific instructions

for GitLab CI/CD in the “.gitlab-
ci.yml” file.
• In this file, you define:
• The structure and order of jobs
that the runner should execute.
• The decisions the runner should
make when specific conditions
are encountered.
• To create a “.gitlab-ci.yml” file:
• Above the file list, select the
branch you want to commit to,
click the plus icon, then select
“New file”:
Get Started:
Creating a sample
“.gitlab-ci.yml” file
• For the Filename, type
“.gitlab-ci.yml” and in the
larger window, paste this
sample code:
• “$GITLAB_USER_LOGIN” and
“$CI_COMMIT_BRANCH” are
predefined variables that
populate when the job runs.
• Click Commit changes.
• The pipeline starts when the
commit is committed.
Get Started: View the status of your pipeline and jobs
• When you committed your changes, a pipeline started.
• To view your pipeline:
• Go to CI/CD > Pipelines.

• To view a visual representation of your pipeline, click the pipeline ID.

Get Started: CI/CD
Concepts
• When you push your commits to a feature branch
in a remote repository, the push triggers the CI/CD
pipeline for the project.
• Then, GitLab CI/CD:
• Runs automated scripts (sequentially or in
parallel) to:
• Build and test your application.
• Preview the changes in a Review
App, the same as you would see on
your localhost
• After the implementation works as expected:
• Get your code reviewed and approved.
• Merge the feature branch into the default
branch.
• GitLab CI/CD deploys your changes
automatically to a production
environment.
 • Disabling GitLab CI/CD in a project does not delete
any previous jobs.
• In fact, the “/pipelines” and “/jobs” pages can still
Get Started: be accessed
• Although it’s hidden from the left sidebar
Enable or menu.
• GitLab CI/CD is enabled by default on new
Disable installations and can be disabled either:
• Individually under each project’s settings.
CI/CD • Site-wide by modifying the settings in
“gitlab.yml” and “gitlab.rb”.
(for source and Omnibus installations
respectively).
Get Started: Enable or Disable CI/CD

• To enable or disable GitLab CI/CD Pipelines in your project:

• Navigate to Settings > General > Visibility, project features, permissions.
• For installations from “source”,
• Expand the Repository section.
• Enable or disable the Pipelines toggle as required. • Open “gitlab.yml” and set “builds” to
“false”.
• Site-wide admin setting:
• Save the file and restart GitLab: “sudo
• You can disable GitLab CI/CD site-wide, by modifying the settings in:
service gitlab restart”.
• “gitlab.yml” for source installations and
• “gitlab.rb” for Omnibus installations.
• Two things to note:
• Disabling GitLab CI/CD affects only newly-created projects.
• Projects that had it enabled prior to this modification work as before.
• For “Omnibus” installations,
• edit “/etc/gitlab/gitlab.rb” and
• add the line: “gitlab_rails['gitlab_default_projects_features_builds'] =
false”
• Save the file and reconfigure GitLab: “sudo gitlab-ctl reconfigure”
 • Contents:
Pipelines • CI/CD Pipelines
• Run a pipeline manually
• Add manual interactions
Pipelines: CI/CD Pipelines
• Top-level component of continuous integration, delivery, and deployment.
• Pipelines comprise:
• Jobs, which define what to do. For example, jobs that compile or test code.
• Stages, which define when to run the jobs.
• For example, stages that run tests after stages that compile the code.
• Jobs are executed by runners.
• Multiple jobs in the same stage are executed in parallel, if there are enough concurrent runners.
• In general,
• Pipelines are executed automatically.
• Require no intervention once created.
• But there are also times when you can manually interact with a pipeline.
Pipelines: Run a pipeline manually

• Pipelines can be manually

executed, with predefined or
manually-specified variables.
• To execute a pipeline manually:
• Navigate to your project’s
CI/CD > Pipelines.,
• Select the Run pipeline
button.
 • to require manual interaction before moving forward in
the pipeline.
• configured using the “when:manual” keyword.

Pipelines: Add • Just click the play button in the pipeline graph to execute
a particular job.

manual interactions • In the example below, the production stage has a job
with a manual action.
 • Contents:
Jobs • Jobs
• Group jobs in a pipeline
• Specifying variables in manual job & Delay
a job
 • Pipeline configuration begins with jobs.
• Jobs are:
• Defined with constraints stating
under what conditions they should
Jobs: Jobs be executed.
• Top-level elements with an
arbitrary name and must contain at
least the “script” clause.
• Not limited in how many can be
defined.
Jobs: Group jobs in
a pipeline
• To create a group of jobs, in the CI/CD
pipeline configuration file, separate each
job name with a number and one of the
following:
• A slash (/), for example, test 1/3, test
2/3, test 3/3.
• A colon (:), for example, test 1:3, test
2:3, test 3:3.
• A space, for example test 0 3, test 1 3,
test 2 3.
• The example on the top right shows three
jobs that are in a group named build ruby
.
Jobs: Specifying variables in manual job & Delay a job
• Supply additional job specific variables from the job page of the manual job to run.
• To access this page, click on the name of the manual job in the pipeline view.

• Use the “when:delayed” keyword to delay a job’s execution for a certain period.
 • Contents:
Variables • CI/CD variables
• Predefined CI/CD variables
• Custom CI/CD Variables
• Create custom variables in the .gitlab-
ci.yml file
• CI/CD variable types
• Pass env var to another job
• Override a defined CI/CD variable
Variables: CI/CD variables

• CI/CD variables are a type of environment variable.

• You can use them to:
• Control the behavior of jobs and pipelines.
• Store values you want to re-use.
• Avoid hard-coding values in your “.gitlab-ci.yml” file.
• You can use predefined CI/CD variables or define custom variables.
Variables: Predefined
CI/CD variables

• You can use predefined CI/CD variables in “.gitlab-

ci.yml” without declaring them first.
• This example shows how to output a job’s stage by
using the CI_JOB_STAGE predefined variable.
• The script outputs the stage for the test_variable,
which is test.
 • Create custom variables for a project:
• In the project’s “.gitlab-ci.yml” file.
• In the project’s settings.
• With the API.
Variables: • Create custom variable for all projects in a
Custom group in the group’s setting.
CI/CD • Create custom variable for all projects in a
GitLab instance in the instance’s settings.
Variables • There are two types of variables: File or
Variable.
Variables: Create custom
variables in the .gitlab-ci.yml file
 • Two types: Variable and File type.
Variables: CI/CD • Variable type variables:
variable types • Consist of a key and value pair.
• Are made available in jobs as environment variables, with:
• The CI/CD variable key as the environment variable name.
• The CI/CD variable value as the environment variable value.
• Use File type CI/CD variables for tools that need a file as input.
• File type variables:
• Consist of a key, value and file.
• Are made available in jobs as environment variables, with
• The CI/CD variable key as the environment variable name.
• The CI/CD variable value saved to a temporary file.
• The path to the temporary file as the environment variable
value.
 • In the job script, save the variable as a .env file.
Variables: Pass env • Save the .env file as an artifacts:reports:dotenv artifact.
var to another job • Set a job in a later stage to receive the artifact by using the dependencies
or the needs keywords.
 Variables:
Override a • Override a variable when running a pipeline manually:
• Go to your project’s CI/CD > Pipelines and select Run
defined CI/CD pipeline.
• Choose the branch you want to run the pipeline for.
variable • Input the variable and its value in the UI.
 • Contents:
Environments • Intro
•
and •
Types of environments
Deployment tier of environments
•
deployments Configure manual deployments
Intro

• Environments describe where code is deployed.

• Each time GitLab CI/CD deploys a version of code to an
environment, a deployment is created.
• GitLab provides a full history of deployments to each
environment and tracks your deployments.
• To view a list of environments and deployments:
• You must have a minimum of Reporter permission.
• Go to the project’s Deployments > Environments
page.
• To view a list of deployments for an environment,
select the environment name, for example, staging.
• Deployments show up in this list only after a
deployment job has created them.
Types of environments

• There are two types of environments:

• Static environments have static names, like staging or
production.
• Dynamic environments have dynamic names.
• Create a static environment:
• You can create an environment and deployment in the
UI or in “.gitlab-ci.yml” file.
• In the UI:
• Go to the project’s Deployments > Environments page.
• Select New environment.
• Enter a name and external URL.
• Select Save.
• In the .gitlab-ci.yml file:
• Specify a name for the environment and optionally, a URL,
which determines the deployment URL.
• Trigger a deployment. (For example, by creating and
pushing a commit.)
Types of environments
• Create a dynamic environment:
• To create a dynamic name and URL for an environment, you
can use predefined CI/CD variables.
• The name is review/$CI_COMMIT_REF_NAME.
• Because the environment name can contain slashes
(/), you can use this pattern to distinguish between
dynamic and static environments.
• The $CI_ENVIRONMENT_SLUG variable is guaranteed to be
unique.

*** You do not have to use the same prefix or only slashes (/) in the
dynamic environment name. However, when you use this format, you
can group similar environments.***
Deployment tier of
environments
• By default, GitLab assumes a tier based on the
environment name.
• But you can still use an environment name like
customer-portal instead of production.
• But the name no longer indicates that the
environment is used for production.
• To indicate that a specific environment is for a
specific use, you can use tiers.
• You can use the deployment_tier keyword to specify
a tier.
Configure manual deployments

• The when: manual action:

• Exposes a play button for
the job in the GitLab UI.
• Means the deploy_prod job
is only triggered when the
play button is clicked.

• You can find the play button in

the pipelines, environments,
deployments, and jobs views.