Continuous DeliveryHelping your business win by bringing the pain forward
Agenda• Introduction• Deployment pipeline• User disruption• Anti-patterns• Adoption• Tools• Conclusion• Q&A
Introduction
Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.Agile Manifesto
What is continuous delivery?Agile methodology for reducing the cost, time and risk ofdelivering incremental changes to use...
Inspired by Lean Startup
Deliver the right thing. Frequently.
«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 wantso...
So how frequently?Deliver fast-enough so that a customer didn’t have timeto change their mind.
Goals- Build the right thing (MVP, eliminate waste)- Reduce lead time (reduce WiP, eliminate bottlenecks)- Reduce cost (op...
Who does continuous delivery?
Let’s rock.
Redefine «Done»Coded Reviewed Checked-in Built Tested DemoedReleased to end-user.
How long would it take your organization to deploy achange that involved just one single line of code?Do you do this on a ...
Reduce risk of release« If it hurts, do it more frequently »
How?
By implementing end-to-end automation ofbuild, deploy, test and release processes.
The Deployment Pipeline
A pull system spanning full product cycle.- Fully automated (with push button approvals)- Visible- Measurable- Paralleliza...
Build only once.
Deploy the same way to every environment.
Fail fast.
Automate everything (almost).
Build quality in.
Keep code always releasable.
Treat every version is a release candidate.Contradicts with traditional approaches.
Quality goes up.People care.
Version everything.Single version. No major/minor/patch increments.
Version control everything.Code, Configuration, Infrastructure…
Test excessively.
Provide recovery plan.
Measure.
- Small increments- Deploy components independently- Leave backward compatibilityAvoid «Big Bang» releases
Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
«Feature branching is apoor man’s modular architecture»Dan BodartBuild a modular platform of micro-services.
Make no exceptionsEven urgent production fix should pass the samedeployment pipeline.
User disruption
downtime deployments0
Blue - Green deployment
Deployment is not a Release.Release is a marketing decision.
Smoke test deployment.Release only after that.
Feature Toggles
Branch by AbstractionMultiple versions in a single code base.
Backward compatibility is a key.State is pain in the ass, but remediable with redundancy
Canary releasingRelease to a subset of users.
Anti-Patterns
Code Freeze ceremony
Deployment rarely / lateAvoid late contact with reality.
Manual environment configuration
Privileged deploy team
Not repeatable process
Slight differences
Manual deploymentsSleep well. Forget 2.00 AM deployments.
Hard to track
Adoption
Forget special «Continuous Delivery» projects
noun1 a feeling of fear or agitation about something that may happen: themen set off in fear and trepidation.2 trembling m...
Raise confidence thatChange can be safe enough.
Do not be afraid to fail.Learn what doesn’t work first, then see how to make it better.
Continuously improveJapanese for "improvement", or "change for the better"Refers to philosophy or practices that focus upo...
Find the right team and start kicking ass.
Tools
Versioning
Build & dependency management
CI + Pipelining
AutomationInfrastructure Script streamliningGlu CapistranoDB migrations
ATDD + Living documentation
Monitoring
Micro-services?
Conclusion
Continuous Delivery challengesyour engineering skills.Are you ready to accept the challenge?
Thank you!
Continuous Delivery
Upcoming SlideShare
Loading in...5
×

Continuous Delivery

2,342

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,342
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • When business come to you and say you’re releasing too frequently – you’re on the right way.
  • Short Lead time  fasterFeedbackCD is expensive. Leanisabout WASTE not COST. High long-term ROI.Increases motivation, as you get things done faster, less stress
  • Большинство– тормозы. Неэффективность процесса и ОПАСНОСТЬ.
  • The most complex task is push button.
  • Create environment where people get responsible for consequence of their action and they will care (DevOpsphylosophy)
  • - Modules / services / entities / staticcontent
  • Whybranches? Parallelization. Multipleversionsoftheapp.Unability to keepapplicationstableduringdevelopment.Onegoal, extracare. No merges. Oneversion, pushupteamsforsynchronizationBringspainforward, raisesprofessionalismIsolationillusion
  • If people have to use feature branch, something is wrong with your architecture.
  • 3WReduce TTD (Time to detect), TTR (Time to recover)
  • Practice makes perfect. Toyota way.
  • CD is hard. Process flaws become visible.
  • Transcript of "Continuous Delivery "

    1. 1. Continuous DeliveryHelping your business win by bringing the pain forward
    2. 2. Agenda• Introduction• Deployment pipeline• User disruption• Anti-patterns• Adoption• Tools• Conclusion• Q&A
    3. 3. Introduction
    4. 4. Our highest priority is to satisfy the customer throughearly and continuous delivery of valuable software.Agile Manifesto
    5. 5. What is continuous delivery?Agile methodology for reducing the cost, time and risk ofdelivering incremental changes to users.
    6. 6. Inspired by Lean Startup
    7. 7. Deliver the right thing. Frequently.
    8. 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. 9. So how frequently?Deliver fast-enough so that a customer didn’t have timeto change their mind.
    10. 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. 11. Who does continuous delivery?
    12. 12. Let’s rock.
    13. 13. Redefine «Done»Coded Reviewed Checked-in Built Tested DemoedReleased to end-user.
    14. 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. 15. Reduce risk of release« If it hurts, do it more frequently »
    16. 16. How?
    17. 17. By implementing end-to-end automation ofbuild, deploy, test and release processes.
    18. 18. The Deployment Pipeline
    19. 19. A pull system spanning full product cycle.- Fully automated (with push button approvals)- Visible- Measurable- Parallelizable
    20. 20. Build only once.
    21. 21. Deploy the same way to every environment.
    22. 22. Fail fast.
    23. 23. Automate everything (almost).
    24. 24. Build quality in.
    25. 25. Keep code always releasable.
    26. 26. Treat every version is a release candidate.Contradicts with traditional approaches.
    27. 27. Quality goes up.People care.
    28. 28. Version everything.Single version. No major/minor/patch increments.
    29. 29. Version control everything.Code, Configuration, Infrastructure…
    30. 30. Test excessively.
    31. 31. Provide recovery plan.
    32. 32. Measure.
    33. 33. - Small increments- Deploy components independently- Leave backward compatibilityAvoid «Big Bang» releases
    34. 34. Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
    35. 35. «Feature branching is apoor man’s modular architecture»Dan BodartBuild a modular platform of micro-services.
    36. 36. Make no exceptionsEven urgent production fix should pass the samedeployment pipeline.
    37. 37. User disruption
    38. 38. downtime deployments0
    39. 39. Blue - Green deployment
    40. 40. Deployment is not a Release.Release is a marketing decision.
    41. 41. Smoke test deployment.Release only after that.
    42. 42. Feature Toggles
    43. 43. Branch by AbstractionMultiple versions in a single code base.
    44. 44. Backward compatibility is a key.State is pain in the ass, but remediable with redundancy
    45. 45. Canary releasingRelease to a subset of users.
    46. 46. Anti-Patterns
    47. 47. Code Freeze ceremony
    48. 48. Deployment rarely / lateAvoid late contact with reality.
    49. 49. Manual environment configuration
    50. 50. Privileged deploy team
    51. 51. Not repeatable process
    52. 52. Slight differences
    53. 53. Manual deploymentsSleep well. Forget 2.00 AM deployments.
    54. 54. Hard to track
    55. 55. Adoption
    56. 56. Forget special «Continuous Delivery» projects
    57. 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. 58. Raise confidence thatChange can be safe enough.
    59. 59. Do not be afraid to fail.Learn what doesn’t work first, then see how to make it better.
    60. 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 | 改善
    61. 61. Find the right team and start kicking ass.
    62. 62. Tools
    63. 63. Versioning
    64. 64. Build & dependency management
    65. 65. CI + Pipelining
    66. 66. AutomationInfrastructure Script streamliningGlu CapistranoDB migrations
    67. 67. ATDD + Living documentation
    68. 68. Monitoring
    69. 69. Micro-services?
    70. 70. Conclusion
    71. 71. Continuous Delivery challengesyour engineering skills.Are you ready to accept the challenge?
    72. 72. Thank you!

    ×