Continuous Integration(CI) and Continuous Delivery(CD) is the collection of best practices that enables development teams to deliver the changes in code more frequently and efficiently.
Through the Continuous Integration, development teams integrate the small changes with share repository and check the version of the code frequently. The technical goal of Continuous Integration is to establish a way to build and test applications with consistency. With the consistency, development teams are more likely to integrate code changes with shared repositories frequently, which leads to better collaboration between teams and better software quality.
The major goal of Continuous Integration is to refine the integration process into a simple, repeatable development task that will reduce the overall build cost and reveal defects in the cycle easily. Success in CI will depend on changes in the culture of the development teams so that there are frequent and iterative builds, and eagerness to deal with bugs as they are found much earlier.
On the other hand, Continuous Delivery means that new features and fixes (done by development teams) pass through the develop-build-test cycle and automate the delivery of new changes to the selected infrastructure environment, which can be production environment or development environment or the testing environment because development teams work in different environments. But when smaller changes are delivered to the production environment frequently, then it can increase the risk at large-scale and may result in the breaking down of systems.
Continuous delivery depends on a deployment pipeline by which the development team automates the testing and deployment processes. This pipeline is an automated system that executes a set of test suites against the build.
In each segment of the deployment pipeline, the build may fail a critical test and alert the team members or it continues on to the next test suite, and the successive test passes the result to the next segment of the pipeline. The last segment of the pipeline will deploy the right build to a production-equivalent environment.
Now the question is how important it is to integrate automated testing in a CI/CD environment?
When smaller changes are delivered to the production environment frequently then some questions occur like how do you test your app efficiently, How can you be sure of the released software’s quality, How do you manage/plan test that fits within budget and resources?
If we think about automated tests, the question is; how often and when should you run automated tests?
the answer is as often as possible and as quickly as possible.
Both answers suggest doing Continuous Integration.
CI allows us to run automated tests after each commit and send feedback with results to developers that their code changes didn’t break any existing unit tests. Good automated tests should cover all functionality that are developed at the end of every sprint, or at least most of them. If we run automated tests only at the end of each cycle/iteration, probably there will be no time to fix issues.
What if a new feature has a bigger impact on the application? For that, we need to perform regression tests continuously throughout the iteration. These regression tests inform the team whether a code change failed one or more of the tests developed across all functional areas of the application.
Here is the list of the top 8 Continuous Integration tools:
- Jenkins
- TeamCity
- Travis CI
- Go CD
- Bamboo
- GitLab CI
- CircleCI
- Codeship
