This is the process by which on commit, the changes are tested against automated test scripts to verify the accuracy of the change against a specification.

The end result would be confidence that the change matches specification.

This process extends continuous integration to preparing a release ready for deployment to a test environment. This could be done manually or scheduled to deploy automatically on a fixed period e.g. every day, week, month

The deployment would be followed by automated tests e.g. integration, performance to prove the deployment quality.

The end result would prove a package ready to be deployed to production.

This process is considered the goal of any organisation. This extends on continuous delivery to add immediate deployment to production so that the users may reap immediate benefits. Ideally this would be a fully automated process with no human interaction. Any failures raised in the previous two stages would prevent the deployment from initiating.

Once the packages are released into production, a series of automated smoke tests would validate the delivery. The release strategy employed would determine how any failures are managed. e.g. automate rollback, notify operator

Deployment is how we deliver - or move - the solution to an environment

Example of environments would be:

• Development
• Integration
  • the new code is combined and validated that it works with existing code
• Test
  • both functional and non-functional tests are run
• Staging
  • test the solution using real data
• Production
  • where the software is made available to users.

Examples of a deployment technique would be:

• Canary
• Blue/Green
• Dark launch

This area involves the packaging medium and therefore the tools available along with the advantages and disadvantages.

A release is the process of making the solution available to the audience.