CI/CD PIPELINE

Understanding the CI/CD Pipeline: What It Is, Why It Matters



Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
When you have a team of developers, each of whom is responsible for a separate feature, you need to integrate the different features before you’re ready for a release. By integrating so frequently, your team can surface errors earlier. And when those are caught, the amount of backtracking needed to find the cause is also much reduced. Therefore, your team can resolve the integration errors much faster.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.





Top of Form

Bottom of Form

How to Practice Continuous Integration
If you want to practice CI, the steps roughly go like this:
1. Developers check out code from the repository to work on it locally. Ideally, they create a new branch for the feature they want to implement.
2. When their feature branch is ready, they run tests locally in their development environments.
3. Once all tests pass, they push the commits to the single source repository.
4. Whenever there are changes on the repository, a CI server checks out the changes and performs a “build and test.” A build and test is when the CI server builds the entire system on the developer’s feature branch and runs all the unit and integration tests.
5. The CI server notifies the team of the integration result. There should generally be four outcomes: failed build, successful build, failed tests, successful tests.
6. If there’s a failure, the team fixes the issue ASAP.
7. When the feature branch is merged to the main branch, they repeat steps 2–6.
8. They continue to develop and repeat the steps 2–6 whenever there’s new code to be checked in to the repository.


.
What’s the Difference Between Continuous Deployment and Continuous Delivery (CD)?
You may be confused by the fact that there’s another term CD can stand for: continuous delivery. So what’s the difference between the two? continuous deployment is about automating the release of a good build to the production environment. In fact, Humble thinks it might be more accurate to call it “continuous release.” On the other hand, continuous delivery is about ensuring that every good build is potentially ready for production release. At the very least, it’s sent to the user acceptance test (UAT) environment. Your business team can then decide when a successful build in UAT can be deployed to production —and they can do so at the push of a button.
To keep it simple, here’s a diagram.