Understanding Continuous Integration[CI] and Continuous Delivery[CD] (Part IV)

Introduction to CI/CD pipelines workflow

Update: This article is part of a Jenkins series. Check out the full series: Part 1, Part 2, Part 3, Part 4

This is a Part IV of Jenkins series as in Part III we saw how to integrate Jenkins with Bitbucket/Github. In this section, we will understand the process of Continuous Integration(CI) and Continuous Delivery(CD) with Jenkins.

What is continuous integration ?

Continuous Integration (CI) is a development practice that requires developers to integrate code to a shared repository several times a day.

All developers write functions and develop new features, services, etc., on their individual workstations. They then commit to the shared Github repository and send Pull Requests (PRs). This happens on a regular basis and as there’s no time frame for when the changes are merged into the master repository, every manual build is a time-consuming process.

A version control system is always being monitored. When a commit is made by a developer, a new build is initiated. If anything fails during the process, the system will notify and send an alert to the admin and the respective developer of the feature. With CI, you can detect problems, bugs, and dependency issues in the earlier phase of the development life cycle.

These automated builds verify all integration checks for any errors. With this approach, we can tackle the integration problems in an earlier phase of the SDLC, which helps build robust applications. Each organization has its own way to implement CI in its eco-system. The steps to achieve the CI server process are shown in the diagram below:

Continuous Integration Server

Automate the process of building, testing, and reporting:

1. All developers working on their own feature branch check in and send a Pull Request upstream several times a day.
2. Version Control System (VCS) receives all the PRs by an individual developer and merges them once they’re verified by the maintainer. It also indicates to the CI server to start the build server process.
3. The build server starts building your project after the integration of the merges and checks if everything works as expected, which includes a continuous testing process.
4. The build reports the status of the build along with detailed results. You can check the logs of the build process and confirm if it meets the desired state.
5. Each integration should have feedback. The feedback is provided based on the result of the previous step.
6. Notify the admin and respective developers of the project of the feedback so that they can take appropriate action to resolve any problems.

What is continuous delivery?

Continuous Delivery (CD) is a software development practice that uses an automation pipeline to release new features. The different environments and application dependencies may cause a problem, so new bugs arise while building the system, which may become difficult to maintain.

Some problems include maintaining different environments, package versions, repositories, rollbacks, etc. Developers are responsible for writing code, and operators are responsible for keeping that code running in production systems. Developers are usually concerned about new features, whereas operators focus on stability. The gap is filled by the continuous DevOps process.

Continuous Delivery Phases (Reference Link)

As per the diagram, the Continuous Delivery process is at the core of SDLC phases, with automation at each phase. The customers can get changes through this approach with end-to-end automation, i.e., single-click deployment, frequent release, etc., so no separate timeframe needs to maintain for deployments. You can also manage, debug, and deploy micro-services.

Your code must be robust, which should cover all the edge test cases that will make the standardized system workflow. This solves the complex problems at the deploying stage and makes the process seamless. You can release many times a day, which helps resolve issues with customer feedback.

CD automates the entire application delivery process. Each commit will trigger the automated build, test the functionality, and deploy the application to the respective environments. We can append the manual push-button to deploy to the production environment to confirm if the current state matches with the desired state, which will reduce the application lifecycle and deliver values faster.

Originally published at What are continuous integration and continuous delivery? on educative.io platform.