4. Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.Agile Manifesto
5. What is continuous delivery?Agile methodology for reducing the cost, time and risk ofdelivering incremental changes to users.
6. Inspired by Lean Startup
7. Deliver the right thing. Frequently.
8. «You can’t just ask customers what they wantand then try to give that to them.By the time you get it built, they’ll wantsomething new.»
9. So how frequently?Deliver fast-enough so that a customer didn’t have timeto change their mind.
10. Goals- Build the right thing (MVP, eliminate waste)- Reduce lead time (reduce WiP, eliminate bottlenecks)- Reduce cost (optimize, automate)- Reduce risk (resilience built-in, small increments)Continuously:
11. Who does continuous delivery?
12. Let’s rock.
13. Redefine «Done»Coded Reviewed Checked-in Built Tested DemoedReleased to end-user.
14. How long would it take your organization to deploy achange that involved just one single line of code?Do you do this on a repeatable, reliable basis?Mary & Tom PoppendieckImplementing Lean Software DevelopmentDetermine cycle time
15. Reduce risk of release« If it hurts, do it more frequently »
17. By implementing end-to-end automation ofbuild, deploy, test and release processes.
18. The Deployment Pipeline
19. A pull system spanning full product cycle.- Fully automated (with push button approvals)- Visible- Measurable- Parallelizable
20. Build only once.
21. Deploy the same way to every environment.
22. Fail fast.
23. Automate everything (almost).
24. Build quality in.
25. Keep code always releasable.
26. Treat every version is a release candidate.Contradicts with traditional approaches.
27. Quality goes up.People care.
28. Version everything.Single version. No major/minor/patch increments.
29. Version control everything.Code, Configuration, Infrastructure…
34. Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
35. «Feature branching is apoor man’s modular architecture»Dan BodartBuild a modular platform of micro-services.
36. Make no exceptionsEven urgent production fix should pass the samedeployment pipeline.
37. User disruption
38. downtime deployments0
39. Blue - Green deployment
40. Deployment is not a Release.Release is a marketing decision.
41. Smoke test deployment.Release only after that.
42. Feature Toggles
43. Branch by AbstractionMultiple versions in a single code base.
44. Backward compatibility is a key.State is pain in the ass, but remediable with redundancy
45. Canary releasingRelease to a subset of users.
47. Code Freeze ceremony
48. Deployment rarely / lateAvoid late contact with reality.
49. Manual environment configuration
50. Privileged deploy team
51. Not repeatable process
52. Slight differences
53. Manual deploymentsSleep well. Forget 2.00 AM deployments.
54. Hard to track
56. Forget special «Continuous Delivery» projects
57. noun1 a feeling of fear or agitation about something that may happen: themen set off in fear and trepidation.2 trembling motion.Embrace changetrepidation | trep·i·da·tion
58. Raise confidence thatChange can be safe enough.
59. Do not be afraid to fail.Learn what doesn’t work first, then see how to make it better.
60. Continuously improveJapanese for "improvement", or "change for the better"Refers to philosophy or practices that focus upon continuousimprovement of processes in manufacturing, engineering, and businessmanagement.Kaizen | 改善