CI/CD Process

7 minutes read
Mike Gonzalez


In recent years, the way we deliver software development has changed. Faster quality software delivery has become a necessity as the market becomes more demanding day by day.

Many frameworks have been published to help developers and managers to solve that problem, but there is one method in particular that gains a lot of fame for its way to increase productivity in software development, we talk about CI/CD.

But first of all, before we continue to explain what is CI/CD, we need to know how it differences with DevOps.

DevOps Culture

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services faster. This speed enables organizations to better serve their customers and compete more effectively in the market.

DevOps influences the application lifecycle throughout the planning, development, delivery, and use phases. Each phase depends on the others and the phases are not specific to a role. In a true DevOps culture, all roles are involved in some way in all phases.

It is important to mention that adopting a DevOps culture is not just about implementing a tool to automate some processes. Having said that, this lecture is going to show the basics of a CI/CD implementation which is only a part of a DevOps Culture. Which is a blow to the belief that having automation is the same as having a DevOps culture.

What is CI/CD?

CI/CD is a method to frequently deliver apps to customers by automating development process and it solves the problems that integrating new code can cause for development and operations teams. The acronym of CI/CD refers to continuous integration, continuous delivery, and continuous deployment.

Continuous Integration

Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository. It’s a solution to the problem of having too many branches of an app in development at once that might conflict with each other.

Continuous Delivery

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository, where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between developers and business teams. To that end, the purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code.

Continuous Deployment

Continuous deployment can refer to automatically releasing a developer’s changes from the repository to production, where it is usable by customers. It addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline.

Automating Process

Automation is a cornerstone of the DevOps movement and facilitates collaboration. Automating tasks such as testing, configuration and deployment frees people up to focus on other valuable activities and reduces the chance of human error.

Here is where CI/CD enters. In order to achieve an automated CI/CD implementation you can define any workflow your application needs to consider new releases delivered are ready and well-tested to be deployed.

Developing modern software requires an automated pipeline that builds, tests, and deploys your application, complete with its required infrastructure.

A pipeline is a way of working in the DevOps world, under Continuous Integration, which allows us to define the complete life cycle of a software development. It is the fundamental component in Continuous Integration, and in the automated software development process.

There is no standard in how a pipeline has to be defined, nonetheless, most of the pipelines share common workflows. All depends on how much control and how big is going to be the project. There are three workflows that are essential to begin with a CI/CD implementation. These are a must-have in any project since you should not avoid them even with a manual implementation.


The objective of the build step is to make sure your application is ready to be used by compiling it.

The quintessential tool for automating builds is Docker, since it package software into containers. A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.

This is great because it does not matter with language you used to developed your project, all can be build into an image with Docker and used in any server compatible with docker or better, in any cloud-based solution that offers running containerized applications natively.

Of course Docker may not be the solution for every case, it is always about of a “depends”, the good part is that you can be as creative as you want to build your application, and this is the step where you can do it.


Testing is important but tedious, for all the work that involves testing every version of your project. So imagine removing manual interactions and passing responsibility to a machine that automatically run all the tests every time a new change is committed.

To accomplish this you must have previously defined and code all the tests your project needs to consider it as a valid version, so you can just define the script to run them here.

There are so much tools to write tests, all depends on what kind of tests you want to do and which language was used to develop the project, so be free to choose any tool that fits better for you.


This is the step where the code is released to be used, either in a development or production environment, once an application is built and tested. This ensures that the version that is deployed will be a ready-to-use application with the least number of errors possible.

Just like in the testing step, there are too many tools to accomplish this step, as well it depends on the language and where the server is located. You may have contracted a cloud-based service that facilitates the deployment or you may have your own server and configurations. In any option, you are free to make your own script that allows you to deploy wherever you need.


Once you understand the value of automating you development process it is time to choose a tool that helps you accomplish it. There are a lot of tools in the market that can be overwhelming to choose just one, since every has something cool to offer. The good part is that every big tech provider has implemented his own CI/CD integration, so it is probably that you don’t have to struggle too much to chose one if you are currently using a related one.

It is important to mention that not every tool cover the CI and the CD at the same time, so that is another parameter to have in mind when you choose one. Finally, here are some of the most famous integrations available in the market:

Gitlab CI/CD

GitLab is a suite of tools for managing different aspects of the software development lifecycle. The core product is a web-based Git repository manager with features such as issue tracking, analytics, and a Wiki.

GitLab allows you to trigger builds, run tests, and deploy code with each commit or push. You can build jobs in a virtual machine, Docker container, or on another server.

Azure DevOps

Azure DevOps Pipelines is Microsoft's main CI/CD platform which traditionally has been used for .NET projects of all kinds. In Azure DevOps, there are also two different pipelines to get your head around: Build pipelines which build artifacts, and release pipelines which can take a build artifact and deploy it to an environment.

Github Actions

GitHub Actions is GitHub's CI/CD pipeline setup. It has been implemented with an open source usage in mind and not any particular technology to build. GitHub was acquired by Microsoft in 2018 and Microsoft has promised to expand the functionality of the Actions and support it.

JetBrains TeamCity

TeamCity is a JetBrains’s build management and continuous integration server.

TeamCity is a continuous integration tool that helps building and deploying different types of projects. TeamCity runs in a Java environment and integrates with Visual Studio and IDEs. The tool can be installed on both Windows and Linux servers, supports .NET and open-stack projects.

Travis CI

Travis CI is a CI service used to build and test projects. Travis CI automatically detects new commits made and pushed to a GitHub repository. And after every new code commit, Travis CI will build the project and run tests accordingly.


Jenkins is an open-source automation server in which the central build and continuous integration process take place. It is a self-contained Java-based program with packages for Windows, macOS, and other Unix-like operating systems. With hundreds of plugins available, Jenkins supports building, deploying, and automating for software development projects.


CircleCI is a CI/CD tool that supports rapid software development and publishing. CircleCI allows automation across the user’s pipeline, from code building, testing to deployment.

You can integrate CircleCI with GitHub, GitHub Enterprise, and Bitbucket to create builds when new code lines are committed. CircleCI also hosts continuous integration under the cloud-managed option or runs behind a firewall on private infrastructure.

Atlassian Bamboo

Bamboo is a continuous integration server that automates the management of software application releases, thus creating a continuous delivery pipeline. Bamboo covers building and functional testing, assigning versions, tagging releases, deploying and activating new versions on production.

Not convinced yet? Stay tuned with our next publications.

We are planing to publish a practical case with Gitlab, in case you already use it or want to know how it works Gitlab with Gitlab CI/CD, it would be a great opportunity to learn how to implemented in your project.

Subscribe to our content