Like the caged birds used in coal mines alerting coal miners of dangerous levels of toxic gases and the need to escape, Canary Deployment alerts DevOps of defective code and features pushed to Production requiring roll-back.
A Canary Deployment is a code-base or feature release performed by deploying a new version of software to a subset of Production nodes, side-by-side with its Production version counterpart. This release is incrementally pushed; first to a small number of users, then ratcheted up until the former release is either ‘turned-off’ (removed) or the new release is rolled-back due to previously undiscovered defects. This process provides control and minimizes the number of users that are impacted if a defective is released.
Running multiple versions of a software release side-by-side in a Production environment requires that the software and the infrastructure be specifically designed for that configuration with a flawless deployment automation methodology.
Continuous Integration, or CI, is the software development practice of merging & integrating individual development work with a ‘Master’, ‘Mainline’ and/or ‘Feature’ Branch constantly, frequently, leading to multiple integration per day. The concept is to unit and system test code changes as often and completely as possible to detect defects early in the delivery process cycle — before user acceptance.
Most of merge and test processes “need to be” automated, removing human intervention. The process requires an agile unit test framework consisting of unit tests, system tests, code toxicity, and code coverage — either the code passes or fails.
- Includes processes from DEV code development check-in thru DEV integration tests.
- Each integration is verified by an automated build process, including unit and end-to-end testing, designed to detect integration errors.
- This approach leads to significantly increased software reliability, reduced integration problems, reduced software and integration defects allowing teams to develop cohesive software with greater velocity.
Continuous Delivery, or CD, is the continual delivery of small branches (packaged) code to ‘Staging’ or Quality Assurance, or QA, environment once the Development team believes the code is deliverable to the Business.
The concept is to deliver developed code to a user base for review and acceptance or rejection by the Business. The process is similar to CI, however, end-users are now involved in the process.
Unit and system tests cannot detect all design issues, business logic, and data completeness, even though processes are documented. Remember, software development is an ‘art’, not a ‘science’.
- Includes processes from DEV code development check-in thru DEV integration with Change Management.
- Development Team prioritizes software change deployability over new feature development.
- Development Team receives immediate, automated feedback on the Production readiness of the code, systems, whenever a change is made.
Continuous Deployment, also CD, is the continual deployment or release of user-reviewed and user-tested code to Production “as soon as it is ready”.
All unit and end-to-end testing has been performed on a stable ‘Production-like’, ‘Production-equivalent’ environment prior to merging and deploying approved code packages through an automated process to the current Production user base branch by a “press of a button”.
Continuous Deployment requires Continuous Integration and Continuous Delivery to be formally in use. CD relies on small changes, or packages, that are constantly tested and that are continuously deployed and released to Production immediately upon verification.
Once a Continuous Deployment process is reality, several pieces of automation are in place – automated CI Build Server(s), CD (Delivery) to Staging environment(s), and CD (deployment) ability to automatically deploy to Production. In an ideal CD (Deployment) workflow, the entire process is automated.
- Development code is queued and checked-in to Development branch.
- CI Server(s) accepts the change
- Unit Tests, System Test, Code Coverage, Toxicity tests are preformed.
- Unit Tests, System Test, Code Coverage, Performance Tests are performed.
- Code either passes or fails tests
- If code passes, CI Server(s) accepts the change
- Unit Tests, System Test, Performance Tests are performed.
- Code ‘can be’ deployed move to Production.
The CI–CD–CD process varies based on Business and Technology alignment, needs, requirements, and approaches.
- Includes processes from DEV code development check-in thru Production release.
- Every change goes through the pipeline and is automatically deployed into production, resulting in multiple production deployments per day.
- Perform push-button deployments of any version of the software to any environment on demand.
- The key test of CD (Deployment) is that a Business sponsor can request a current development version of the software be deployed into Production at a moment’s notice; and nobody would “bat an eye” or panic.
Continuous Customer Feedback
Continuous Customer Feedback, or CCF, is the constant / continual customer response(s), feedback, & reviews that provide both subjective and empirical data (points) causing improvement.
- Constant / continual review with measurement of impact.
- Immediate Feedback loop to Backlog (Intake).
- Consistent reviews and retrospectives from Product Owners.
DVT – Design Validation Test
Design Validation Test, or DVT, requires multiple builds (or units) function as expected meeting all functional requirements and appearance requirements.
EVT – Engineering Validation Test
Engineering Validation Test, or EVT, requires several builds (or units) function as expected meeting all functional requirements.
PVT – Production Validation Test
Production Validation Test, or PVT, requires complete functional builds (multiple complete units) function repeatedly as expected meeting all functional requirements, appearance requirements, and with great manufacturability.