What is CI/CD? How CI/CD works? Understanding how Gitlab CI/CD can be used? Undersanding what is ".gitlab-ci.yml" and how can it be used for CI/CD?

NOTE: The following docs hels us with gaining basic knowledge about CI/CD for a quick get-start. If you wish to learn more about CI/CD please use alternate docs too.

What is CI/CD?

CI and CD stand for continuous integration and continuous delivery/continuous deployment. In very simple terms, CI is a modern software development practice in which incremental code changes are made frequently and reliably. Automated build-and-test steps triggered by CI ensure that code changes being merged into the repository are reliable. The code is then delivered quickly and seamlessly as a part of the CD process. In the software world, the CI/CD pipeline refers to the automation that enables incremental code changes from developers’ desktops to be delivered quickly and reliably to production.

How CI/CD works?

The below provided image which is sourced from google, provides us a simple depiction about how a typical CI/CD pipeline works.

Understanding how Gitlab CI/CD can be used?

GitLab CI/CD is the part of GitLab that we use for all of the continuous methods (Continuous Integration, Delivery, and Deployment). With GitLab CI/CD, we can test, build, and publish our software with no third-party application or integration needed.

More about the continous methods can be found in gitlab official document. The link for the same has been provided below

• Continuous Integration (CI)
• Continuous Delivery (CD)
• Continuous Deployment (CD)

How Gitlab CI/CD works?

Note: The following information was replicated from the offical gitlab docs for quick reference. The same could be found in the follwing - https://docs.gitlab.com/ee/ci/introduction/#gitlab-cicd-workflow

GitLab CI/CD fits in a common development workflow.

You can start by discussing a code implementation in an issue and working locally on your proposed changes. Then you can push your commits to a feature branch in a remote repository that’s hosted in GitLab. The push triggers the CI/CD pipeline for your 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.

If something goes wrong, you can roll back your changes.

This workflow shows the major steps in the GitLab process. You don’t need any external tools to deliver your software and you can visualize all the steps in the GitLab UI.

Undersanding what is .gitlab-ci.yml and how can it be used for CI/CD?

Note: The following information was replicated from the offical gitlab docs for quick reference. The same could be found in the follwing - https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html

.gitlab-ci.yml is a yaml file which generally contains the configurations for the CI/CD.

In the .gitlab-ci.yml file, you can define:

• The scripts you want to run.
• Other configuration files and templates you want to include.
• Dependencies and caches.
• The commands you want to run in sequence and those you want to run in parallel.
• The location to deploy your application to.
• Whether you want to run the scripts automatically or trigger any of them manually.

Without the .gitlab-ci.yml in the root of the Gitlab repository the CI/CD pipeline cannot be triggered. When you add a .gitlab-ci.yml file to your repository, GitLab detects it and an application called GitLab Runner runs the scripts defined in the jobs.

Sample .gitlab-ci.yml :

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

In this example, the build-code-job job in the build stage runs first. It outputs the Ruby version the job is using, then runs rake to build project files. If this job completes successfully, the two test-code-job jobs in the test stage start in parallel and run tests on the files.

The full pipeline in the example is composed of three jobs, grouped into two stages, build and test. The pipeline runs every time changes are pushed to any branch in the project.

To know more about the configuration options for your GitLab .gitlab-ci.yml file, head over to - https://docs.gitlab.com/ee/ci/yaml/