This document discusses continuous delivery, which is an agile methodology for frequently delivering incremental software changes to users. It involves fully automating the build, deployment, testing and release processes through a deployment pipeline. This reduces costs and risks while ensuring that quality software is delivered to users quickly. The document outlines various goals and best practices of continuous delivery, such as automating everything possible, testing excessively, and avoiding anti-patterns like code freezes or manual deployments. It also discusses tools that can help with continuous delivery and adopting this approach.

1. Continuous Delivery
Helping your business win by bringing the pain forward

2. Agenda
• Introduction
• Deployment pipeline
• User disruption
• Anti-patterns
• Adoption
• Tools
• Conclusion
• Q&A

3. Introduction

4. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Agile Manifesto

5. What is continuous delivery?
Agile methodology for reducing the cost, time and risk of
delivering incremental changes to users.

6. Inspired by Lean Startup

7. Deliver the right thing. Frequently.

8. «You can’t just ask customers what they want
and then try to give that to them.
By the time you get it built, they’ll want
something new.»

9. So how frequently?
Deliver fast-enough so that a customer didn’t have time
to 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 Demoed
Released to end-user.

14. How long would it take your organization to deploy a
change that involved just one single line of code?
Do you do this on a repeatable, reliable basis?
Mary & Tom Poppendieck
Implementing Lean Software Development
Determine cycle time

15. Reduce risk of release
« If it hurts, do it more frequently »

16. How?

17. By implementing end-to-end automation of
build, 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

21. Build only once.

22. Deploy the same way to every environment.

23. Fail fast.

24. Automate everything (almost).

25. Build quality in.

26. Keep code always releasable.

27. Treat every version is a release candidate.
Contradicts with traditional approaches.

28. Quality goes up.
People care.

29. Version everything.
Single version. No major/minor/patch increments.

30. Version control everything.
Code, Configuration, Infrastructure…

31. Test excessively.

32. Provide recovery plan.

33. Measure.

34. - Small increments
- Deploy components independently
- Leave backward compatibility
Avoid «Big Bang» releases

35. Avoid branches
- True Continuous Integration - work only in mainline
- No feature branches
- No release branches

36. «Feature branching is a
poor man’s modular architecture»
Dan Bodart
Build a modular platform of micro-services.

37. Make no exceptions
Even urgent production fix should pass the same
deployment pipeline.

38. User disruption

39. downtime deployments
0

40. Blue - Green deployment

41. Deployment is not a Release.
Release is a marketing decision.

42. Smoke test deployment.
Release only after that.

43. Feature Toggles

44. Branch by Abstraction
Multiple versions in a single code base.

45. Backward compatibility is a key.
State is pain in the ass, but remediable with redundancy

46. Canary releasing
Release to a subset of users.

47. Anti-Patterns

48. Code Freeze ceremony

49. Deployment rarely / late
Avoid late contact with reality.

50. Manual environment configuration

51. Privileged deploy team

52. Not repeatable process

53. Slight differences

54. Manual deployments
Sleep well. Forget 2.00 AM deployments.

55. Hard to track

56. Adoption

57. Forget special «Continuous Delivery» projects

58. noun
1 a feeling of fear or agitation about something that may happen: the
men set off in fear and trepidation.
2 trembling motion.
Embrace change
trepidation | trep·i·da·tion

59. Raise confidence that
Change can be safe enough.

60. Do not be afraid to fail.
Learn what doesn’t work first, then see how to make it better.

61. Continuously improve
Japanese for "improvement", or "change for the better"
Refers to philosophy or practices that focus upon continuous
improvement of processes in manufacturing, engineering, and business
management.
Kaizen | 改善

62. Find the right team and start kicking ass.

63. Tools

64. Versioning

65. Build & dependency management

66. CI + Pipelining

67. Automation
Infrastructure Script streamlining
Glu Capistrano
DB migrations

68. ATDD + Living documentation

69. Monitoring

70. Micro-services?

71. Conclusion

72. Continuous Delivery challenges
your engineering skills.
Are you ready to accept the challenge?

73. Thank you!