What is CICD? CICD Pipelines and Tools

As the topic suggests this tutorial is all about the CICD, one of the best practices of DevOps. Before we go into it, let’s first discuss how things work in traditional methodologies and how organizations landed on the DevOps approach.

In traditional methodologies like waterfall model, all the phases are sequential and dependent on the previous phase. The testing phase begins only after the whole development phase is over. If any changes are required during the cycle, it is not possible. To integrate any change, the whole cycle has to be repeated.

The major drawback of such traditional models was that they did not support any change during the ongoing development cycle. Due to this, a new methodology called ‘Agile’ was introduced. In agile methodology, the focus is on the rapid delivery of the software; development and testing processes run simultaneously, and the client is also involved in each phase.

Due to client involvement, continuous feedback is available and if any change is requested by the client, unlike traditional methods, it is incorporated in the ongoing development cycle.

Moving one step further from the agile model, DevOps, a new approach that focuses on collaboration between development and operations teams to rapidly deliver high-quality products was introduced. To achieve these goals of rapid delivery and high quality, one of the best practices implemented by DevOps teams is CICD.

What is CICD?

CICD stands for Continuous Integration and Continuous Delivery. It enables rapid code changes with more reliability and fewer risks. It increases the efficiency of the project and makes sure that the delivered software is of the highest quality. 

Continuous Integration (CI) is software development or coding practice in which any code changes made by the developer in his/her private workspace are committed to the central repository regularly. After this, automated builds and tests are conducted by the CI system on the code changes that helps in detecting bugs more quickly and improving software quality.


Continuous Delivery (CD) is another practice that follows CI. Post CI, once the build stage has been completed, the CD automatically prepares the code for further release on production or staging environments. The CD process involves at least one manual approval point in which only after getting the approval from the developer or any other resource, the code changes are deployed to the production or staging or any other environments.


Continuous Deployment (CD) come next in the chronology. There is a subtle difference between Continuous Delivery and Continuous Deployment. In Continuous Deployment, the code changes are automatically deployed to the selected environment without getting any manual approval from the developer or any other resource.

CICD Pipeline

Now, after discussing the terms involved in the CI/CD concept, let’s understand the CI/CD pipeline.
CI/CD pipeline is a process that helps in automatically deploying the code changes made by the developers to the production. Its first step is to merge code changes in the central repository and the end step is to deploy the final tested code on the production.

CI/CD pipeline can be divided into the following steps-

  • Source Code – In this step, developers of the development team commit code changes to a version control system. 
    Tools that can be used in this step are Git, Subversion. These tools have been discussed in brief in the next section.
  • Build – In this step, once the code is committed to the central repository, the builder tool will build the code and run the unit tests to validate the code. Both these actions, build and test run simultaneously. Unit tests are written by the developers.
    Tools that can be used in this step are Maven, NAnt, Ant, Grunt, Gradle, Make, SBT, etc. The build tool depends on the programming language used in the project.
  • Staging – In this step, the code is deployed on the staging environment. Here, various tests such as integration, system, performance, component, UAT are performed. Teams can also create separate environments to run these tests.
    A staging environment is a production-like environment that also uses the production-like database.
  • Production – Here, the code deployed on the staging environment, after necessary tests, is deployed on the production. In the Continuous Delivery process, manual intervention is required to deploy the code on the production whereas, in the Continuous Deployment process, code is automatically deployed to the production after passing various tests on the staging environment.

In the above steps, if any error is found, the developers will be notified. Once the error is fixed, the code will be merged into the repository and the whole cycle will be repeated. 

Tools used in CICD Pipeline

There are various tools that can be used during the CI/CD pipeline as mentioned above. This section discusses some of them in brief.

Version Control Systems

  • Git – It is a free and open source distributed version control system. It was created by Linus Torvalds and was released in 2005. Its latest version 2.27 was released in June 2020. Some of the advantages of Git are distributed development where the developer has a local repository, branching model and better security controls.
  • Subversion – Subversion is an open-source centralized version control system. It was created by CollabNet Inc.in 2000. It is written in C programming language and its latest version 1.14 was released in May 2020. Some of the benefits of Subversion are easy controls that can be learned quickly, better numbering conventions, handling of image files better than other version control systems.

Build Tools

  • Maven – It is a build automation tool written in Java. It was developed by Apache Software Foundation in 2004. Its latest version 3.6.3 was released in November 2019. Maven has plugins for C/C++ and .NET framework. Maven provides dependency management, easy project setup, and a common structure for all projects.
  • Grunt – Grunt is a JavaScript Task Runner written in Node.js. It was released in 2012 and its latest version 1.2.0 was released in July 2020. 
  • Apache Ant – Ant is an open-source software tool for automating build processes. It is written in Java and its latest version 1.10.8 was released in May 2020.

CI/CD Tools

  • Jenkins – It is a widely used, free, and open-source automation CI/CD tool helping in automating steps of software development such as building, testing, and deploying. It was created by Kohsuke Kawaguchi in 2011.
    It is written in Java and its latest version 2.240 was released in June 2020. Some of the advantages of Jenkins are that it is easy to use and easily configurable, it allows integration with various tools using plugins and it is platform-independent. 
  • TeamCity – It is a CI server developed by JetBrains in 2006. It is written in Java and its latest version 2019.2 was released in December 2019. It is not free, but it offers a free plan where users can get 100 build configurations.
    Benefits of TeamCity includes the ability to run multiple builds and tests on different platforms simultaneously and integration of third party reports.
  • Bamboo – It is a CI/CD server created by Atlassian in 2007 and it is written in Java. Its latest version 6.10 was released in September 2019.
    Some of the benefits of Bamboo are that it can import data from Jenkins, it has easy to use UI, built-in Git branching workflows, Jira, and BitBucket integration.
  • GoCD – It is an open-source tool developed by ThoughtWorks in 2007. It is written in Java and Ruby. Its latest version 19.12.0 was released in 2019.

Conclusion

CICD practices are quickly becoming popular among organizations due to its benefits. Any bugs present in the code are found during the build step that helps the developer to fix the bug early in the cycle.
CICD helps in identifying more bugs compared to the traditional development cycle. It also helps in reducing manual labor as it uses automation tests. To get the maximum benefit of the CICD process, the organizations should try to automate more and more steps of the pipeline.

Leave a Comment