Every job posting I see nowadays has the term "CI/CD pipeline" in it. It's like if you're a programmer, you have to learn about it. So, let's start with the basics.
Continuous Integration (CI)/ Continuous Delivery (CD) is a method to frequently deliver apps to customers by introducing automation into the stages of app development. It's actually a solution to Integration Hell. Integration Hell refers to the point in production when members on a delivery team integrate their individual code. In traditional software development environments, this integration process is rarely smooth and seamless, instead resulting in hours or perhaps days of fixing the code so that it can finally integrate.
Continuous integration
As the name suggests, integrate continuously. As a developer, merge your changes back to the main branch as often as possible.
Implement small changes and check in code to version control repositories frequently. The changes are validated by creating a build as well as running automated tests against the build. Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.
The technical goal of CI is to establish a consistent and automated way to build, package, and test applications. With consistency in the integration process in place, teams are more likely to commit code changes more frequently, which leads to better collaboration and software quality.
Example
Let's say we have multiple developers working simultaneously on different features of the same app. However, if we are to merge all branching source code together on one day, the resulting work can be tedious, even manual, and time-intensive. That’s because when a developer working in isolation makes a change to an application, there’s a chance it will conflict with different changes being simultaneously made by other developers.
Continuous integration (CI) helps developers merge their code changes back to a shared branch more frequently – even daily.
Once a developer’s changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated testing, typically unit and integration tests, to ensure the changes haven’t broken the app. This means testing everything from classes and function to the different modules that comprise the entire app. If automated testing discovers a conflict between new and existing code, CI makes it easier to fix those bugs quickly and often.
Continuous delivery
Continuous delivery is making sure to release new changes to quickly in a sustainable way.
In other words, a developer’s changes to an application are automatically bug tested and uploaded to a repository for example GitHub or GitLab, where they can then be deployed to a live production environment by the operations team.
You need to automate your release process on top of having automated your testing and you can deploy your application at any point of time by clicking on a button. Continuous delivery is an answer to the problem of poor visibility and communication between developers and business teams. The purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code.
You can release daily, weekly, monthly or whatever suits your business requirements. However, if you deploy to production as early as possible in small batches then it will be easy to troubleshoot in case of a problem.
Continuous deployment
With this practice, every change that passes all stages of your production pipeline is released to your customers.
There's no human intervention, and only a failed test will prevent a new change to be deployed to production. It is a good way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it. It addresses the problem of overloading operations teams with manual processes that slow down app delivery.
In practice, continuous deployment means that a developer’s change to a cloud application could go live within minutes of writing it (assuming it passes automated testing). This makes it much easier to continuously receive and incorporate user feedback.
Final Words…
Continuous integration and continuous delivery require continuous testing because the objective is to deliver quality applications and code to users. Continuous testing is often implemented as a set of automated regression, performance, and other tests that are executed in the CI/CD pipeline.
One of the best known open source tools for CI/CD is the automation server Jenkins. Jenkins is designed to handle anything from a simple CI server to a complete CD hub. Although, there are tons of tools available and even GitLab has integrated CI/CD pipeline in it.
Sources
basics CI/CD Continuous Deployment Continuous Integration
