Continuous Delivery – automating build and self-testing

After fully implementing CI in the organization, you can move on to the next process and implement Continuous Delivery.

The following is a schematic of Continuous Delivery. In this process, the Dev Team, Testing Team, and Software Configuration Team work together to integrate the latest code and make it available for the acceptance test. Once this acceptance test has completed successfully, the product is available for delivery:

Continuous Delivery aims to deliver quality software in a very fast manner. It has the ability to continuously deliver changes, such as new features, bug fixes, and configuration changes into UAT, staging, and production. It also helps to deliver work in small batches frequently, so that issues can be uncovered at an early stage.

Continuous Delivery differs from Continuous Integration as it will feed the business logic for tests. For Continuous Integration it will do the unit test and unable to catch all the design issue. You can deliver the code for a code review in this process.

The following are the key differences between CI and Continuous Delivery:

You can do Continuous Delivery when:

• The product is deployable throughout its life cycle
• Working on new features, your team's priority will be keeping the software deployable
• Someone makes changes to the production readiness; you will get fast and automated feedback
• You can deploy any version of the software to environments such as UAT, staging, or production from the push-button

Continuous Delivery can be achieved by CI of the software developed by the team, building the executables and running automated tests to detect any issue. You can push the executable into a production-like environment to ensure that it will work in production. To do this, you can use the Deployment Pipeline.

Clients or business teams should be able to ask for the current working development version to be deployed to production, at any given time. This version has already passed the acceptance test, so there should be no objection from any of the team.   

You can achieve Continuous Delivery with close and collaborative relationships between the teams involved in software delivery. You can also carry out extensive automation for all parts in the process using the Deployment Pipeline.

This Deployment Pipeline contains different stages such as Build Automation, Continuous Integration, Test Automation, and Deployment Automation. Let's go through all the stages in brief:

• Build Automation: This is the first process; the build happens automatically using tools rather than manually.
• CI: In CI, developers check in the code many times on a shared repository, the automated build will verify this check in, inform the team if there are any defects, issuers or errors, and carry out iterative and incremental software delivery.
• Test Automation: A new version of the application has been tested to ensure that it contains all the required functionalities with quality. It is important that it also verifies the security, performance, and compliance verified by the pipeline. This stage involves many automated activities.
• Deployment Automation: It should be automated to provide the reliable delivery of new functionalities to the users within minutes.