What is CI/CD? Continuous Integration & Continuous Delivery

In today’s culture of wanting more and more, one of the top challenges for software companies is quickly responding to market and customer demands. To address this concern, a solution was implemented: Continuous Integration (CI) and Continuous Delivery (CD). CI/CD practices are currently the most widely accepted choice to shorten software development and delivery cycle time. Read on to find out more about CI/CD and how these practices are performed.

What is Continuous Integration?

Pioneered by Gary Booch, software integration was first integrated as one of the key practices of Extreme Programming. Software integration may not be necessary for stable projects, but it is essential for projects with frequent changes. After all, waiting to integrate often results in integration conflicts and can take too much time to resolve, leading to project delays.

Continuous integration (CI) helps ensure that software components work together. Integration should be completed frequently; if possible, on an hourly or daily basis.

In a CI practice, developers build, run, and test code on their own workstations before committing code to the version control repository. After changes are made to the repository, a chain of events is put into motion. A typical first step in this chain is to build the latest version of source code. If the build is successful, unit tests are executed. If unit testing succeeds, the build is deployed to test environments where system tests are performed (usually using automated tests). The team is notified about the status of this process, and a report is delivered to provide details, such as build number, defects, and the number of tests.

A CI pipeline typically involves the following tasks:

• Detect changes in the source code repository (new commits appear)
• Source code quality analysis
• Build
• Execute all unit tests
• Execute all integration tests
• Generate deployable artifacts
• Report status

If one of the steps above fails:

• Integration may stop or continue depending on defect severity and configuration
• Results are notified to the team via email or chat system
• Team fixes defects and commits again
• Tasks are performed again

What is Continuous Delivery?

Continuous delivery (CD) picks up where continuous integration ends. While CI is the process to build and test automatically, CD deploys all code changes in a build to the testing or staging environment.

CD makes it possible to release builds to the production environment when needed. Allowing the team to deploy at will, CD effectively reduces time to market.

Before deploying software to production, the CD process includes performing automated system testing, unit testing (including API testing and load testing), and integration testing. The steps from CI to CD are usually completed automatically, including automated testing at the unit, integration, and system levels. As tests can fail at any level and environment, CI/CD must include a feedback channel to quickly report failures to developers.

Dependent on policies and processes defined by teams, developers may do the following with CI/CD:

Step 1: Before committing changes, developers check to see if the current build succeeded. If not, fix errors before committing new changes.

Step 2: If the current build succeeded, reset the workstation with the build’s configuration.

Step 3: Build and test locally to ensure the update does not break any functionality. If successful, commit new changes.

Step 4: Allow CI to complete with new changes.

Step 5: If the build fails, stop and fix errors on local workstations. Go back to Step 3.

Step 6: If the build passes, continue working on other items.

CI/CD Workflow Pipeline

A CI/CI pipeline is a path for delivering a unit of change that starts from development to delivery, usually consists of the following main phases:

Phase 1: Commit
When developers complete a change, they commit the change to the repository.

Phase 2: Build
Source code from the repository is integrated into a build.

Phase 3: Automate tests
Automated tests are run against the build. Test automation is an essential element of any CI/CD pipeline.

Phase 4: Deploy
The built version is delivered to production.

Importance of Test Automation for CI/CD

Test automation is a crucial component of any CI/CD pipeline. The benefits of applying CI/CD cannot be realized if there is a lack of automated testing and a low level of test coverage. Teams need to perform automated testing at all levels including unit, integration, and system testing.

Unit test

Covers units of code such as methods, classes, and API services. Effective unit testing significantly increases test coverage for the whole system.

Integration test

Ensure modules and parts of the system work together smoothly.

System test

Runs on the entire system to simulate active users. The test environment should be as close to the production environment as possible.

Teams also need to apply automation testing for multiple testing types such as functionality, usability, performance, load, stress, and security.

Crucial Software for the CI/CD Pipeline

Many software tools are available to support implementing CI/CD practices. These tools range from repository management such as Github and Bitbucket, Jenkins for build automation, and Selenium and Katalon Studio for test automation.

Katalon Studio provides a comprehensive set of features for API, Web, and mobile testing. It can be easily integrated into a CI/CD pipeline to handle unit (API services), integration, and system testing.

Conclusion

CI and CD are two DevOps best practices as they tackle the misalignment between developers and operational team. With the presence of automation, developers can release changes and new features more frequently, while operation teams have better overall stability.
Check out Katalon Studio for better test automation and CI/CD implementation.

Originally published at https://www.katalon.com/resources-center/blog/ci-cd-introduction/