Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
34 lines (27 sloc) 8.62 KB

Continuous Delivery check

Part of the Multi-team Software Delivery Assessment (README)

Copyright © 2018-2019 Conflux Digital Ltd

Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Permalink: SoftwareDeliveryAssessment.com

Based on the key practices in the book Continuous Delivery by Jez Humble and Dave Farley and the summary of the Continuous Delivery practices at CDchecklist.info

Purpose: Assess the awareness and performance of the team regarding key Continuous Delivery practices

Method: Use the Spotify Squad Health Check approach to assess the team's answers to the following questions, and also capture the answers:

Question Tired (1) Inspired (5)
1. Release Candidate - Every Check-in Leads to a Potential Release (Chapter 1) We have special "Release Candidate" builds occasionally Any check-in can generate a build that might go to Production without a further build
2. Done - Done Means Released [that is, released into Production and not causing problems] (Chapter 1) Our Definition of Done means "feature tests have passed" Our Definition of Done means that the changes are deployed to Production with monitoring to ensure they have not broken anything
3. Automated Config - Configuration should always be performed by automated processes using values taken from your configuration repository (Chapter 2) Many of our applications and tests are configured manually each time All configuration is done using scripts
4. Config Options - It should be easy for anyone to see what configuration options are available for a particular version of an application across all environments it will be deployed into. (Chapter 2) We have to run diffs against different files, some in version control, some taken from live servers We have an API or UI to show the config options deployed to any environment
5. Broken Builds - Don’t Check In on a Broken Build (Chapter 3) [except to fix the broken build!] We cannot easily know when our team has broken a build We guard the build with care and never check-in on a broken build
6. Failing Tests - Don’t Comment Out Failing Tests (Chapter 3) We switch off failing tests to get the build or pipeline working We trust our tests; if the tests are failing, then something is wrong and we go and fix it
7. Binaries - Only Build Your Binaries Once [no special 'release candidate' builds] (Chapter 5) We have multiple different builds and then merge to create the final Release Candidate We have only a single build to produce a binary artifact which then gets promoted through all environments with no additional merging or building needed
8. Stop The Line - If Any Part of the Pipeline Fails, Stop the Line [everyone stops feature work and fixes the problem] (Chapter 5) The pipeline fails so often that it is difficult to know which team broke the build If the pipeline fails, it is very clear which team is responsible and so we stop our work immediately to fix the problem
9. Idempotent Deployment - Ensure the Deployment Process Is Idempotent [we can deploy the same version repeatedly with the same result] (Chapter 6) It is difficult to get repeatable deployments We can redeploy the same version many times with the same result
10. Stubs - Use Stubs to Simulate External Systems [treat almost every other system as 'external'!] (Chapter 8) There are few stubs available and we do not have enough time to write the stubs ourselves The stubs we consume and write are good quality and give us a high degree of confidence that our tests are working well
11. API Replay - Record Interactions against a Service or Public API (Chapter 9) We have no way to record requests/responses from a remote API We record key requests/responses from remote APIs which we use to build high-fidelity integration tests
12. Blue-Green - Use Blue-Green Deployments [at a granular level] (Chapter 10) - this means any mechanism that allows you to test a new version alongside an existing version and rollback to the older version if necessary We do not use any blue-green deployment techniques We use fine-grained blue-green deployment techniques - at the level of individual services
13. Environment History - It should be possible to see a history of changes made to every environment, including deployments. (Chapter 11) It is difficult to see the history of changes in an environment We have a nice dashboard or log of changes to every environment
14. DB Changes - Decouple Application Deployment from Database Migration [and from other data-rich services] (Chapter 12) - this relates to shared databases We must deploy our application or service together with the database or data layer Our application or service is completely decoupled from the underlying database or data layer
You can’t perform that action at this time.