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.

Recipes for Continuous Delivery

1,034 views

Published on

SEE UPDATED VERSION: https://www.slideshare.net/gsluthra/recipes-for-continuous-delivery-thoughtworks-geeknight

In this presentation, I cover techniques and best practices for CD. The idea is to explain the rationale behind CI, Branching, Feature Branches, Trunk Based Development, Feature Toggles, and related techniques that aid in faster delivery.

Special Thanks to Luminaries like Martin Fowler, Paul Hammant, Jez Humble, Pete Hodgson and many ThoughtWorkers for their material. I have mentioned links to them on respective slides.

Published in: Software
  • Be the first to comment

Recipes for Continuous Delivery

  1. 1. RECIPES FOR CONTINUOUS DELIVERY Gurpreet Luthra - Lead Consultant, ThoughtWorks 1 _zenx_
  2. 2. TOPICS 2 • Continuous Integration (CI) • Continuous Deployment (CD?) / Continuous Delivery (CD) • Phoenix Servers • Branching for Release • Feature Branches • Trunk Based Development • Pull Request Model • Toggles • Branch by Abstraction & Strangulation
  3. 3. 3 CONTINUOUS INTEGRATION
  4. 4. 3 CONTINUOUS INTEGRATION https://www.thoughtworks.com/continuous-integration
  5. 5. 4
  6. 6. 4 https://www.thoughtworks.com/continuous-integration
  7. 7. THE PRACTICES 5 • Maintain a single source repository • Automate the build • Make your build self-testing • Every commit should build on an integration machine • Keep the build fast • Test in a clone of the production environment • Make it easy for anyone to get the latest executable • Everyone can see what’s happening • Automate deployment
  8. 8. HOW TO DO IT 6 • Developers check out code into their private workspaces. • When done, commit the changes to the repository. • The CI server monitors the repository and checks out changes when they occur. • The CI server builds the system and runs unit and integration tests. • The CI server releases deployable artefacts for testing. • The CI server assigns a build label to the version of the code it just built. • The CI server informs the team of the successful build.
  9. 9. TEAM RESPONSIBILITIES 7 • Check in frequently • Don’t check in broken code • Don’t check in untested code • Don’t check in when the build is broken • Don’t go home after checking in until the system builds
  10. 10. THE UNDERLYING ASSUMPTION 8 • The quality and impact of your CI processes are solely dependant on the quality of your TESTS. • If you don’t write good quality tests, with reasonable coverage, all the CI infrastructure in the world can’t protect you.
  11. 11. THE UNDERLYING ASSUMPTION 8 • The quality and impact of your CI processes are solely dependant on the quality of your TESTS. • If you don’t write good quality tests, with reasonable coverage, all the CI infrastructure in the world can’t protect you. WRITE GOOD TESTS!!!
  12. 12. CONTINUOUS DELIVERY 9 Image from: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment
  13. 13. CONTINUOUS DELIVERY 9 Image from: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment
  14. 14. PHOENIX SERVERS 10 • Configuration Drift • Snowflake servers • No SSH servers • Immutable Servers • Phoenix servers PLEASE READ: http://martinfowler.com/bliki/PhoenixServer.html and http://martinfowler.com/bliki/ImmutableServer.html
  15. 15. VM (OR CONTAINERS) AS BUILD AGENTS 11 SLIDE COPIED FROM: http://decks.eric.pe/pantheon-ci/#9
  16. 16. BUILD AGENTS AS PHONEIX SERVERS 12
  17. 17. BUILD AGENTS AS PHONEIX SERVERS 13
  18. 18. BUILD AGENTS AS PHONEIX SERVERS 14
  19. 19. PHOENIX SERVERS 15
  20. 20. PHOENIX SERVERS 15 Diagram and full article at: https://boxfuse.com/blog/no-ssh
  21. 21. BRANCHING FOR RELEASE 16 Image from: http://paulhammant.com/blog/branch_by_abstraction.html
  22. 22. BRANCHING FOR RELEASE 17 FOR EACH RELEASE HOW MUCH EFFORT DO YOU PUT IN TO CREATE CI PIPELINES ?
  23. 23. FEATURES BRANCHES 18 Image from: http://blogs.riskotech.com/riskfactor/post/An-Alternate-Branching-Strategy.aspx
  24. 24. THE REALITY OF FEATURE BRANCHES 19 Image from: http://paulhammant.com/blog/branch_by_abstraction.html
  25. 25. BRANCH TRACKING 20
  26. 26. A GIT BRANCHING MODEL 21
  27. 27. A GIT BRANCHING MODEL 21 Image from: http://nvie.com/posts/a-successful-git-branching-model/
  28. 28. TRUNK BASED DEVELOPMENT 22 • Trunk Based Development (TBD) is where all developers (for a particular deployable unit) commit to one shared branch under source-control called “trunk” or “mainline”. • Branches are made only for a release in the shared repository. • Trunk always stays GREEN. • Developers never break the build with any commit. Alternatively, broken commits are immediately rolled back. Or such commits may be blocked before being merged with the trunk. • Developers don’t work in ISOLATION, in their “happy branches” for days. Update your workstation daily!
  29. 29. TRUNK BASED DEVELOPMENT 23 Image from: http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/
  30. 30. PULL REQUEST MODEL 24 master fork’s master Fork branch feature-1 branch branch Raise pull request Update to latest Raise pull request feature-2 branch review + no mergereview + merge review + merge
  31. 31. PULL REQUEST MODEL 25 Image from: code.tutsplus.com/tutorials/travis-ci-what-why-how--net-34771
  32. 32. TRUNK BASED DEVELOPMENT 26 Feature branching is a poor man’s modular architecture, instead of building systems with the ability to easily swap in and out features at runtime/deploy time, you’re coupling yourself to the source control providing this mechanism through manual merging. - Daniel Bodart Mentioned By http://martinfowler.com/bliki/FeatureBranch.html AND http://sethgoings.com/feature-branching
  33. 33. TRUNK BASED DEVELOPMENT 27 OK. I WILL TRY & AVOID FEATURE BRANCHES. HOW DO I ENSURE I CAN DEVELOP BIG FEATURES, YET, KEEP TRUNK GREEN & STABLE?
  34. 34. FEATURE TOGGLES 28 • Release Toggles • Business Toggles • Build Time Toggles • Run Time Toggles • A/B Testing • Canary Releases • Rollback in production PLEASE READ http://martinfowler.com/articles/feature-toggles.html Pete Hodgson
  35. 35. EXAMPLES 29 • Introduce a simple search box on your home page • Add a new feature to favorite products + My Favorite page (client side only, nothing on server side) • Upgrade from Java7 and Java 8 (slowly across servers) • Improve your search algo (in case it returns no results, then apply, distance algo) • Change upload logic for images (earlier each image was assigned a thread). New logic: Create a queue, perform a de- dup, assign to a thread, batch size of 5, upload. • Add FB Integration (FB Like + Count -- pulled from FB) • Change JS code to use Require.JS for dependencies • Introduce dependency injection via Spring/Guice • Change Repository code from Hibernate to Toplink
  36. 36. IMPLEMENTATION 30 • Simple IF statement (top most layer) • DB / File / Code based configuration • Polymorphic Substitution / Injection • Plugin Based / Dynamic JAR Lookup / Discovery • Hook based extensions • Toggle Based Frameworks (Use Google!) • Many more..
  37. 37. BRANCH BY ABSTRACTION 31
  38. 38. BRANCH BY ABSTRACTION 31
  39. 39. BRANCH BY ABSTRACTION 31
  40. 40. BRANCH BY ABSTRACTION 31
  41. 41. BRANCH BY ABSTRACTION 31 IMAGES AND ARTICLE: http://martinfowler.com/bliki/BranchByAbstraction.html
  42. 42. BRANCH BY ABSTRACTION 32 • Technique for making large scale changes in a gradual way • Use an abstraction layer to allow multiple implementations to co-exist • Use the notion of one abstraction and multiple implementations to perform the migration from one implementation to the other • Ensure that the system builds and runs correctly at all times YES. IT’S JUST GOOD OBJECT ORIENTED DESIGN.
  43. 43. STRANGULATION PATTERN 33 • Slowly strangulate one system for another. • Slow strangulate one model / one component for another. PLEASE READ http://agilefromthegroundup.blogspot.in/2011/03/strangulation-pattern-of-choice-for.html IMAGE FROM: https://dzone.com/articles/legacy-java-applications
  44. 44. WHERE TO NEXT? 34 • Write good tests. Make them blazing fast. Depend on them! • Commit & push frequently to Trunk. Build should be ALWAYS Green. • Every morning, pull latest code to your machine. • Consider using Immutable Servers / Phoenix Servers. • Figure out creative ways to keep software ready-for-release. • Plan for rollbacks, or for functionality switches. • Consider strategies like Toggles or Branch-by-Abstraction. • Don’t work in ISOLATED branches. • Be thoughtful in your code… and in your design.
  45. 45. WHERE TO NEXT? 34 • Write good tests. Make them blazing fast. Depend on them! • Commit & push frequently to Trunk. Build should be ALWAYS Green. • Every morning, pull latest code to your machine. • Consider using Immutable Servers / Phoenix Servers. • Figure out creative ways to keep software ready-for-release. • Plan for rollbacks, or for functionality switches. • Consider strategies like Toggles or Branch-by-Abstraction. • Don’t work in ISOLATED branches. • Be thoughtful in your code… and in your design. AIM FOR Continuous Delivery!
  46. 46. THANK YOU 35 Gurpreet Luthra - Lead Consultant, ThoughtWorks _zenx_ Thank you for all your thoughts on CI & CD by Martin Fowler, Paul Hammant, Jez Humble, Pete Hodgson, ThoughtWorkers and of course Calvin & Hobbes

×