Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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.                ...
What is continuous delivery?Agile methodology for reducing the cost, time and risk of        delivering incremental change...
Inspired by Lean Startup
Deliver the right thing. Frequently.
«You can’t just ask customers what they want            and then try to give that to them.      By the time you get it bui...
So how frequently?Deliver fast-enough so that a customer didn’t have time                 to change their mind.
Goals    Continuously:-   Build the right thing (MVP, eliminate waste)-   Reduce lead time (reduce WiP, eliminate bottlene...
Who does continuous delivery?
Let’s rock.
Redefine «Done»Coded Reviewed Checked-in Built Tested Demoed            Released to end-user.
Determine cycle timeHow long would it take your organization to deploy a change that involved just one single line of code...
Reduce risk of release« If it hurts, do it more frequently »
How?
By implementing end-to-end automation of build, deploy, test and release processes.
The Deployment Pipeline
A pull system spanning full product cycle.-   Fully automated (with push button approvals)-   Visible-   Measurable-   Par...
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.
Avoid «Big Bang» releases- Small increments- Deploy components independently- Leave backward compatibility
Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
«Feature branching is a                 poor man’s modular architecture»                                         Dan Bodar...
Make no exceptionsEven urgent production fix should pass the same             deployment pipeline.
User disruption
0   downtime deployments
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 / late Avoid 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
Embrace changetrepidation | trep·i·da·tionnoun1 a feeling of fear or agitation about something that may happen: the    men...
Raise confidence that        Change can be safe enough.
Do not be afraid to fail.Learn what doesn’t work first, then see how to make it better.
Continuously improveKaizen | 改善Japanese for "improvement", or "change for the better"Refers to philosophy or practices tha...
Find the right team and start kicking ass.
Tools
Versioning
Build & dependency management
CI + Pipelining
AutomationInfrastructure       Script streamlining                      Glu   Capistrano                     DB migrations
ATDD + Living documentation
Monitoring
Micro-services?
Conclusion
Continuous Delivery challenges                      your engineering skills.Are you ready to accept the challenge?
Thank you!
Continuous Delivery
Upcoming SlideShare
Loading in …5
×

Continuous Delivery

982 views

Published on

Presentation from JUG, 14.04.2013

  • Be the first to comment

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 of delivering 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 want and then try to give that to them. By the time you get it built, they’ll want something new.»
  9. 9. So how frequently?Deliver fast-enough so that a customer didn’t have time to change their mind.
  10. 10. Goals Continuously:- 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)
  11. 11. Who does continuous delivery?
  12. 12. Let’s rock.
  13. 13. Redefine «Done»Coded Reviewed Checked-in Built Tested Demoed Released to end-user.
  14. 14. Determine cycle timeHow 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
  15. 15. Reduce risk of release« If it hurts, do it more frequently »
  16. 16. How?
  17. 17. By implementing end-to-end automation of build, 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. Avoid «Big Bang» releases- Small increments- Deploy components independently- Leave backward compatibility
  34. 34. Avoid branches- True Continuous Integration - work only in mainline- No feature branches- No release branches
  35. 35. «Feature branching is a poor man’s modular architecture» Dan BodartBuild a modular platform of micro-services.
  36. 36. Make no exceptionsEven urgent production fix should pass the same deployment pipeline.
  37. 37. User disruption
  38. 38. 0 downtime deployments
  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 / late Avoid 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. Embrace changetrepidation | trep·i·da·tionnoun1 a feeling of fear or agitation about something that may happen: the men set off in fear and trepidation.2 trembling motion.
  58. 58. Raise confidence that Change 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 improveKaizen | 改善Japanese for "improvement", or "change for the better"Refers to philosophy or practices that focus upon continuousimprovement of processes in manufacturing, engineering, and businessmanagement.
  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 streamlining Glu Capistrano DB migrations
  67. 67. ATDD + Living documentation
  68. 68. Monitoring
  69. 69. Micro-services?
  70. 70. Conclusion
  71. 71. Continuous Delivery challenges your engineering skills.Are you ready to accept the challenge?
  72. 72. Thank you!

×