Hey everyone, as said earlier I’ll be covering topics: Tekton Pipeline but before that, I’ll be covering:
In this blog, I’ll be covering what is CI/CD, how it works and why is it needed.
What is CI/CD
CI and CD are the acronyms frequently used in development practices and DevOps (will be covered later). CI stands for Continuous Integration, which is a fundamental DevOps Practice where developers frequently merge codes in the central repository. Whereas CD stands for Continuous Deployment/Delivery.
Continuous Integration (CI)
Continuous integration (CI) is the process of automatically detecting, pulling, building, and (in most cases) doing unit testing as source code is changed for a product.
It is a development/DevOps practice, that makes developer merge code in a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily. With it a developer practices integrating the code with the whole team.
How does continuous integration work?
The idea behind CI is automation. The way it works is that the shared repository is watched and any changes made would be detected, a copy of the code is pulled and then an automated process builds the application and runs a set of tests to confirm that the newest code integrates with what’s currently in the master branch.
There are many ways the detection of changes works:
It works the same as HTML Pooling. The monitoring program repeatedly asks the source management system, if there are any changes and only When the source management system has new changes, the monitoring program is alerted about the changes made, then the monitoring program performs it’s the automated process of building and testing.
In this case, the monitoring program will periodically, i.e. at every interval build the code and run the test regardless of whether there are any changes or not. Ideally, if there are no changes, then nothing new is built, so this doesn’t add much additional cost.
In this case monitoring system does not ask or do anything for detection. Instead, whenever a change is made in the repository it’ll send an alert/message (or can be called notification) to the monitoring system about the change.
Why is Continuous Integration needed or what are it’s advantages?
It eradicates manual deployment that has human errors. Automation of the self-testing build based on set criterion eliminates the need for human intervention during implementation.
Moreover, The production environment is free from staging errors because the system quarantines bugs during the regular inspections. Errors are easily identified and the team can discuss steps to mitigate the problems that arise after each test.
You can read more advantages of CI here.
What is Continuous Delivery/Deployment? (CD)
Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way. Hence, it is a practice of automating the entire software release process.
The continuous delivery process typically includes at least one manual step of approving and initiating a deploy to production. In complex systems with multiple dependencies, the continuous delivery pipeline may include additional steps, which are either manual or automatic.
Continuous Deployment is a step up from Continuous Delivery in which every change in the source code is deployed to production automatically, without explicit approval from a developer.
There acronym CD is used both for Delivery and Deployment.
Now, let’s understand each term in detail.
Continuous Delivery is a software development practice where you build software in such a way that the software can be released to production at any time.
or it can be better explained as:
Continuous Delivery is the automation of steps to safely get changes into production. Where Continuous Deployment focuses on the actual deployment, Continuous Delivery focuses on the release and release strategy. An elusive goal would be a “push of a button” to get changes into production. That “push of a button” is Continuous Delivery.
What are the advantages of Continuous Delivery?
The main advantage is that the code is ready to deploy at all times.
Another advantage could be that it makes the process/path of releasing easy. The path to a release can be long and tough, as it includes traversing all the needed steps and modifications needed to propagate/support changes or new features can be a winding one. Continuous Delivery brings all of the testing steps, incremental/environmental deployments, and validation steps to safely get changes into production.
Continuous deployment means that every change that you make, goes through the pipeline, and if it passes all the tests, it automatically gets deployed into production. So, with this approach, the quality of the software release completely depends on the quality of the test suite as everything is automated.
What are the advantages of Continuous Deployment?
With continuous deployment, the developer can check code and get a pass/fail notification within minutes. If an issue is detected, they can resolve it and have the new version submitted and into production within a few minutes. If no issues are detected, the new code is moved automatically into production. Hence it increases the delivery velocity.
You can read more advantages of Continuous Delivery/Deployment here.
You can also read about when to use Continuous Delivery with Continuous Deployment, as generally only Continuous Deployment is followed/used here.
Note, the CI/CD is part of DevOps practice and I’ll be covering what DevOps is, why is it needed and how it works in the next blog.
I have also not gone into details about the CI/CD, you can read about the various tools used for CI/CD pipeline. I have included the links below.