The Continuous Delivery Model

Transcription

1 The Continuous Delivery Model

2 The Goal Our goal as software professionals is to deliver useful, working, high quality software to users as quickly as possible Speed is essential because there is an opportunity cost associated with not delivering software you only start to get a return on your investment once your software is released Feedback is essential: Any change should trigger the feedback process Feedback must be delivered as soon as possible The delivery team must receive feedback and then act on it

3 The Goal Corporate governance is concerned about conformance compliance assurance oversight responsible, transparent management Business governance is concerned about performance value creation It is possible to achieve both conformance and performance This principle is right at the heart of continuous delivery

4 Continuous Integration It s a practice, not a tool James Shore Continuous Integration on a Dollar a Day

5 Continuous Integration It is a development practice that requires developers to integrate code into a shared repository several times a day Each check-in is then verified by an automated build, allowing teams to detect problems early - CI minimises integration costs

6 Deployment Pipeline The deployment pipeline is modelling your value stream It s a paradigm for moving code from check-in to production in a controlled way It depends on having some foundations in place: good configuration management automated scripts for building and deploying automated tests

7 Test Strategy The shortest feedback loops are created through sets of automated tests that are run upon every change to the system A combination of testing strategies leads to high test coverage

8 Test Strategy It is important to constantly question the value a test provides versus the cost it has in maintenance or the amount it constrains your implementation By following the guidelines of the test pyramid, we can avoid decreasing the value of the tests through large boated test suites that are expensive to maintain and execute

9 The paradox of automation An automated deployment pipeline is more than a tool that delivers a product, the value provided makes it a product in its own right

10 Disambiguation

11 Continuous Deployment Make the final step of the deployment pipeline automatic It forces you to do the right thing

12 Continuous Delivery is not a trophy Achievement shifts upon: adding or improving features adding or removing services consolidating or reallocating resources

13 Managing Releases Blue-Green Deployments A zero-downtime release is one which the actual process of switching users from one release to another happens nearly instantaneously The key to zero-downtime releases is decoupling the various parts of the release process so they can happen independently as far as possible

14 Managing Releases Blue-Green Deployments The idea is to have two identical versions of the production environment One flavour is shadow domain releasing in which staging and production are the blue and green environments

15 Managing Releases Blue-Green Deployments

16 Managing Releases Canary Releasing Canary releasing involves rolling out a new version of an application to a subset of the production servers to get fast feedback (like a canary in a coal mine)

17 Managing Releases Canary Releasing

18 Managing Releases Canary Releasing class Sample : IFeature {} bool PercentChance(int percent) { return new Random().Next(0, 100) < percent; } if (Feature<Sample>.Is().Enabled && PercentChance(20)) { // 20% } else { // 80% }

19 Manage and provision infrastructure Use an approach to manage all infrastructure based upon the following principles: - the desired state of your infrastructure should be specified through version-controlled configuration - infrastructure should be autonomic that is, it should correct itself to the desired state automatically - you should always know the actual state of your infrastructure through instrumentation and monitoring

20 Manage and provision infrastructure Azure Resource Manager

21 Monitoring and Alerting

22 Version Control - GitFlow Incompatible with Continuous Integration

23 Version Control Feature branching Short lived feature branches produce less complex changes Usage of a build server as well as a CI server

24 Version Control Feature branching There are 3 key assumptions: Feature branches should always be short-lived Reviews should be timely Build should always be well monitored Source [Steve Smith - The Death of Continuous Integration]

25 Version Control Feature branching Feature branches will last longer than a day because the only constraint is developer discipline Reviews last long as it takes for two people to come together and share responsibility for a single outcome Build will be slower and more broken because build feature branching is predisposed towards asynchronous integration; builds are not waited to complete and getting slower; context switch when build is broken Incompatible with Continuous Integration Source [Steve Smith - The Death of Continuous Integration]

26 Version Control Feature branching

27 Version Control Feature branching

28 Version Control Stack Overflow Developer Survey 2015 Developers do what the tool is encouraging to do

29 Version Control Trunk based development Adaptive scheduling always releasable codebase Collaborative design constant communication, cohesive evolutionary architecture Operational and business empowerment decouple release from launch Compatible with Continuous Integration Source [Steve Smith - The Death of Continuous Integration]

30 Managing components and Dependencies How to keep your application releasable? How do you manage large teams working on multiple releases if you check-in every change in to the mainline? good componentization of your software incremental development feature hiding This requires more care in architecture and development but the benefits far outweighs this effort

31 Managing components and Dependencies Hide new functionality until it is finished (make it inaccessible to users) Make all changes incrementally analysis plan is an important part; you re solving the problem of keeping the application working as you go along, preventing the pain at the end Branch by abstraction excellent pattern to turn monolith into modular an abstraction is created over the piece to be changed a new implementation is created in parallel with the existing implementation the original implementation is removed (and optionally the abstraction layer too) Use components to decouple parts of your application that change at different rate

32 Build and Deployment Scripting

33 Build and Deployment Scripting