Continuous Delivery in Motion

The deck we used for the XConf Jaipur 2016.

Transcript

1. CONTINUOUS DELIVERY IN MOTION Avinash Chugh & Praveer Gupta 1
2. AGENDA 2 ▪The business case ▪A typical delivery pipeline ▪Putting it into practice
3. THE BUSINESS CASE 3
4. WHAT DOES IT TAKE FOR A BUSINESS TO SUCCEED 4 Faster time to market Being responsive to customer needs
5. TRUE AGILITY MEANS 5 Collaboration Rapid response to change Working software
6. CONTINUOUS DELIVERY 6 Frequent Releases Reliable Releases
7. PERILS OF LONG RELEASE CYCLES 7 1 1 2 1 2 3 4 1 2 3 Release Time Unreleased changes = risk Risk Value
8. BENEFITS OF FREQUENT RELEASES 8 1 2 3 4 1 1 2 1 2 3 Release Release Release Released changes = value
9. 9 HOW CAN I FREQUENTLY RELEASE SOFTWARE HOW CAN I BUILD SOFTWARE INCREMENTALLY HOW CAN I CONFIDENTLY RELEASE NEW SOFTWARE
10. 10 Release Iteration Story Commit MODERN DEVELOPMENT CYCLE
11. 11 Series of commits Release MANY COMMITS FORMING A RELEASE
12. Release candidates Series of commits WHAT IF EACH COMMIT WERE A RELEASE Releases on demand
13. DELIVERY PIPELINE 13
14. A DELIVERY PIPELINE 14 App Service Library
15. 2. CI server checks out & compiles code 4. Code analysis 5. Create & publish artifact 15 3. Unit tests 1. Developer commits code to SCM Commit Stage COMMIT STAGE
16. 16 2. Retrieve artifact 4. Run smoke tests 5. Run acceptance tests 3. Deploy artifact 1. Prepare environment Acceptance Stage ACCEPTANCE STAGE
17. 17 2. Retrieve artifacts 4. Run smoke tests 3. Deploy artifacts 1. Prepare environment Deploy Stage DEPLOY STAGE One-click deployments
18. 1 2 3 4 5 6 A LOT HAPPENS BEFORE A RELEASE 18 Regression testing User Acceptance Integration Infrastructure Setup Performance testing Security Audit
19. Increasing confidence Faster feedback SHORTER RELEASE CYCLE 19 Commit Live
20. TESTING PYRAMID 20 End to end – business facing Localized – technology facing ▪Slower feedback ▪Higher cost of change
21. DEVELOPMENT IN SILOS 21 Merge Merge Trunk Anti-pattern: Feature branching
22. LOW REUSE AND MERGE ISSUES 22 Merge Merge Trunk 2 2 3 4 2 3 1 1 1 1 4 5 2 3 1 2 1 3 2 1 1 4 3 2 1 4 3 2 1 4 5 2 3
23. COLLABORATIVE DEVELOPMENT 23 Trunk 1 2 3 4 5 1 1 3 4 2 4 5 2 1 3 2 4 3 Key principle: Continuous Integration
24. CONTINUOUS INTEGRATION PRACTICES 24 ▪ One component, one repository ▪ Everyone commits to trunk every day ▪ No branches
25. 25 CD Tools IAAS PAAS Mobile Systems Delivering software CONTINUOUS DELIVERY IN DIVERSE CONTEXTS
26. CD IN PRACTICE 26
27. MANAGING LARGE CODE BASES 27 ▪ Dependency management ▪ Service Oriented Architectures ▪ Microservices
28. RELEASING INCOMPLETE WORK 28 [featureToggles] wobblyFoobars: true flightyForkHandles: false Config File <toggle name=wobblyFoobars> ... various UI elements </toggle> some.jsp forkHandle = (featureConfig.isOn(‘flightlyForkHandles)) ? new FlightyForkHander(aCandle) : new ForkHandler(aCandle) other.java Pattern: Feature toggles
29. GUIDELINES FOR FEATURE TOGGLES 29 ▪ Use them only when needed ▪ Prefer feature hiding ▪ Remove toggles once feature is live
30. MAKING BIG CHANGES 30 Application New Library Library Pattern: Branch by abstraction
31. 31 Interface implements Application New Library Library MAKING BIG CHANGES
32. 32 Interface implements Application New Library Library MAKING BIG CHANGES
33. 33 Interface implements Application New Library Library MAKING BIG CHANGES
34. 34 Interface implements Application New Library MAKING BIG CHANGES
35. 35 Application New Library MAKING BIG CHANGES
36. WRAPPING UP 36
37. WHAT WE COVERED 37 ▪Fast feedback, and short release cycles ▪Keeping WIPs to a minimum ▪If it’s hard, do it more often ▪Trunk-based development ▪The need for automation ▪Feature toggles ▪Branch by abstraction
38. SO MUCH MORE TO EXPLORE 38 ▪Deployment strategies ▪Automated deployments ▪Configuration management ▪Infrastructure provisioning ▪Cloud deployments ▪Virtualization ▪Tooling support
39. 39 ADDITIONAL READING
40. @thoughtworks THANK YOU