Continuous Delivery (The newest)
Download as PPTX, PDF3 likes1,137 views
This document discusses continuous delivery, which aims to frequently deliver valuable software to users through an automated deployment pipeline in order to reduce costs, time to market, and risks. It outlines the goals of continuous delivery as building the right product through minimum viable products, reducing lead times and costs through optimization and automation, and reducing risks through resilience and small incremental changes. The document provides strategies for implementing continuous delivery including establishing a deployment pipeline, prioritizing user experience, adopting tools to support continuous integration, deployment and monitoring.
Continuous Delivery (The newest)
- 1. Continuous Delivery Helping your business win by bringing the pain forward
- 2. Eduards Sizovs Founder & Consultant ... Interested in bringing Continuous Delivery to your company? No problem! Just let us know Software development & consulting www.craftsmans.lv @eduardsi eduards.sizovs@gmail.com
- 3. Agenda • Introduction • Deployment pipeline • User disruption • Anti-patterns • Adoption • Tools • Conclusion • Q&A
- 4. Introduction
- 5. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Agile Manifesto
- 6. What is continuous delivery? Agile methodology for reducing the cost, time and risk of delivering incremental changes to users.
- 7. Inspired by Lean Startup
- 8. Deliver the right thing. Frequently.
- 9. «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.»
- 10. So how frequently? Deliver fast-enough so that a customer didn’t have time to change their mind. ! Continuous Deployment is a different thing.
- 11. 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) - Reduce stress (things goes faster, motivation up) Continuously:
- 12. Who does continuous delivery?
- 13. Let’s rock.
- 14. Redefine «Done» Coded Reviewed Checked-in Built Tested Demoed Released to end-user. According to the latest trends: removed from production (A/B, experiments, backward compatibility)
- 15. 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
- 16. Reduce risk of release « If it hurts, do it more frequently »
- 17. How?
- 18. By implementing end-to-end automation of build, deploy, test and release processes.
- 20. A pull system spanning full product cycle. - Fully automated (with push button approvals) - Visible - Measurable - Parallelizable
- 22. Build only once.
- 23. Deploy the same way to every environment.
- 24. Fail fast.
- 27. Keep code always releasable.
- 28. Treat every version is a release candidate. Contradicts with traditional approaches.
- 29. Quality goes up. People care.
- 30. Version everything. Single version. No major/minor/patch increments (except API).
- 31. Version control everything. Code, Configuration, Infrastructure…
- 33. Provide recovery plan. … and reduce Mean Time To Recovery (MTTR)
- 34. Measure everything. - Code Quality - Cycle Time - Lead Time - Build, test duration - # of Built failures - # of Defects
- 35. - Small increments - Deploy components independently - Leave backward compatibility Avoid «Big Bang» releases
- 36. Avoid branches - True Continuous Integration - work only in mainline - No feature branches - No release branches
- 37. «Feature branching is a poor man’s modular architecture» Dan Bodart Build a modular platform of micro-services. ... Interested in bringing Micro Services to your company? No problem! Just let us know www.craftsmans.lv
- 38. Make no exceptions Even urgent production fix should pass the same deployment pipeline.
- 39. User disruption
- 41. Blue - Green deployment
- 42. Deployment is not a Release. Release is a marketing decision.
- 43. Smoke test deployment. Release only after that.
- 45. Branch by Abstraction Multiple versions in a single code base.
- 46. Backward compatibility is a key. State is pain in the ass, but remediable with redundancy Dealing with backward compatible code: http://goo.gl/MMEO70
- 47. Canary releasing Release to a subset of users.
- 48. Anti-Patterns
- 50. Deployment rarely / late Avoid late contact with reality.
- 55. Manual deployments Sleep well. Forget 2.00 AM deployments.
- 56. Hard to track Who? When? Why? What?
- 57. Adoption
- 58. Forget special «Continuous Delivery» projects
- 59. 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
- 60. Raise confidence that Change can be safe enough.
- 61. Do not be afraid to fail. Learn what doesn’t work first, then see how to make it better. Engineering Velocity: Shifting the Curve at Netflix http://goo.gl/D10wGH
- 62. 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 | 改善
- 63. Find the right team and start kicking ass.
- 64. Tools
- 66. Build & dependency management
- 67. CI + Pipelining + Deployments
- 68. Automation Infrastructure Script streamlining DB migrations LHM (soundcloud/lhm) Schema-less DBs?
- 69. Configuration Management Apache ZooKeeper Apache Curator Netflix Archaius github.com/Netflix/archaius
- 70. ATDD + Living documentation
- 74. Conclusion
- 75. Continuous Delivery challenges your engineering skills. Are you ready to accept the challenge?
- 76. Thank you!
Editor's Notes
- #6: 15 лет назад.
- #11: When business come to you and say you’re releasing too frequently – you’re on the right way.
- #12: Short Lead time faster Feedback
- #16: Большинство – тормозы. Неэффективность процесса и ОПАСНОСТЬ.
- #19: The most complex task is push button.
- #30: Create environment where people get responsible for consequence of their action and they will care (DevOps phylosophy)
- #31: - Modules / services / entities / static content
- #35: Постоянно упускаем нужный момент. Как продать необходимость улучшений? Lead time – from request to delivery Cycle time – work started to delivery
- #37: Why branches? Parallelization. Multiple versions of the app. Unability to keep application stable during development. One goal, extra care. No merges. One version, push up teams for synchronization Brings pain forward, raises professionalism Isolation illusion
- #38: If people have to use feature branch, something is wrong with your architecture.
- #48: Ask.fm way (Gradual releases) Ask.fm way (Confiugration per node, per group)
- #51: (Aggregating change)
- #61: Code reviews, Pair Programming Safety nets Blameless culture, Team’s Responsibility Reduce TTD (Time to detect), TTR (Time to recover)
- #63: Practice makes perfect. Toyota way.
- #66: Bintray – Maven, RPM, Debian
- #76: CD is hard. Process flaws become visible.