You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »


This page describes in beginner terms the usefulness of the Continous Integration / Continous Delivery methodology. If you had no experience in these practices, read this document first and then move forward to GitLab and Jenkins implementations.

The repository with examples and enabled CI/CD can be found here https://gitlab.eufus.eu/bpogodzinski/ach-tutorials


1.  What is CI/CD?

CI/CD is a set of practices that automate the building, testing, and deployment stages of software development. Automation reduces delivery timelines and increases reliability across the development life cycle. It also removes the burden of manual checking if the program compiles and runs correctly.

The CI in CI/CD stands for continuous integration. The CD refers to continuous delivery or continuous deployment, depending on how much of the software development process you want to automate. There are some differences between the two, but for simplicity's sake, we are going to call this stage continuous delivery.

In layman terms:

  • Continuous Integration builds your project and runs tests every time you commit new code to your git repository. Tests check if your changes don't break things. Thanks to that, after every commit you know if your code still works.
  • Continuous Delivery takes your built and tested project and sends it to a server that runs your application. This makes more sense if your code is, for example, a web application or service that is available on the internet. 

2.  Why use CI/CD?

There are multiple reasons why to use CI/CD. 

  • CI pipeline can be used as a way of documenting how to build/run your code. 
  • Various types of automated tests identify bug issues at an early stage.
  • CI/CD embrace automation

3.  How to use CI/CD?

Many websites that host git repositories (like GitHub, GitLab, Bitbucket) allow you to use their integrated CI/CD. There may be some differences between them in terms of CI/CD pipeline defining syntax, but the core idea remains the same.

There are also standalone platforms that can be hosted on your own servers like Jenkins, Travis, or CircleCI.

The core idea is to write a file (eg. Jenkinsfile, .gitlab-ci.yml) that will define a pipeline that builds and test your code. Then, CI/CD service will read that file and build your project accordingly to what is specified in the file. If any of the stages that are defined in the pipeline fails, the service will let you know what went wrong.

  • No labels