Small Batch Deployments 2019-04-02

99d4c0ed3c8027ea1c37b53d6441d042?s=47 sullis
April 02, 2019

Small Batch Deployments 2019-04-02

Small batch deployments
Sean Sullivan
April 2, 2019

#devops #continuousdelivery

99d4c0ed3c8027ea1c37b53d6441d042?s=128

sullis

April 02, 2019
Tweet

Transcript

  1. Small Batch Deployments Sean Sullivan April 2, 2019

  2. Principles of Continuous Delivery continuousdelivery.com

  3. 2003: Poppendieck * book published May 2003 Remember the rule

    of small batches: If you integrate changes in small batches, it will be infinitely easier to detect and fix problems.
  4. 2006: Poppendieck * book published September 2006 Work in small

    batches Reduce project size. Shorten release cycles. Stabilize. Repeat.
  5. http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html software should be designed, written, and deployed in small

    batches 2009: Eric Ries * February 2009
  6. 2009: Flickr * Velocity Conference, June 2009 https://www.youtube.com/watch?v=LdOe18KhtT4

  7. 2009: Flickr * Velocity Conference, June 2009 https://www.youtube.com/watch?v=LdOe18KhtT4

  8. https://omniti.com/seeds/online-application-deployment-reducing-risk.html 2010: Theo Schlossnagle * published March 2010 micro-releases: releases

    must never get too large instead amortize risk with small, controlled releases
  9. 2010: Facebook * Velocity Conference, June 2010 a culture of

    making very frequent small changes if you've only changed one thing at a time, it is really easy to figure out what broke the site https://www.youtube.com/watch?v=nEmJ_5UHs1g Robert Johnson
  10. 2010: Etsy * Velocity Conference, June 2010 https://www.kitchensoap.com/2010/06/24/ops-meta-metrics-velocity-2010-slides/ John Allspaw

  11. 2010: Etsy * Velocity Conference, June 2010 https://www.kitchensoap.com/2010/06/24/ops-meta-metrics-velocity-2010-slides/ John Allspaw

  12. * book published August 2010 2010: Continuous Delivery Imagine that

    you released frequently, so the delta between what is currently in production and the new release is small. If that were true, the risk of release would be greatly diminished
  13. incremental deployment 2012: gilt.com deploy early, deploy often * Portland

    Oregon, January 2012
  14. Work in small batches. With a small batch size, you

    are reducing the amount of complexity that has to be dealt with at any one time by the people working on the batch. Break down large releases into small units of deployment 2012: Damon Edwards http://dev2ops.org/2012/03/devops-lessons-from-lean-small-batches-improve-flow/ * published March 2012
  15. each release is a rollback point small incremental releases actually

    help reduce risk 2012: Sam Newman * GeeCon, May 2012
  16. https://www.joelonsoftware.com/2012/07/09/software-inventory/ * published July 2012 2012: Joel Spolsky If you’re

    already shipping monthly, figure out how to ship weekly. Keep pushing the bar on more and more frequent deployment of smaller and smaller changes.
  17. 2012: PuppetConf https://twitter.com/RealGeneKim/status/251457175128530944 * tweet, September 2012

  18. 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? * October 2012 2012: Jez Humble
  19. 2012: Don Reinertsen https://www.youtube.com/watch?v=cAMyGVSj9m4 * December 2012

  20. 2012: Don Reinertsen https://www.youtube.com/watch?v=cAMyGVSj9m4 * December 2012

  21. 2013: gilt.com continuous delivery is critical Every release is small.

    You know what's changed in production. If it doesn't work, rollback is simple * Surge conference, September 2013
  22. We love to deploy new code incrementally hundreds of times

    a day. And there's good reason for that: it's safer overall. Incremental deploys are easier to understand and fix than one gigantic deploy once a year. https://zachholman.com/talk/move-fast-break-nothing/ 2014: Github * published October 2014
  23. https://codeascraft.com/2015/02/20/re-introducing-deployinator-now-as-a-gem/ 2015: Etsy We deploy code about 40 times per

    day. This allows us to push smaller changes we are confident about and experiment at a fast rate. Jayson Paul * published February 2015
  24. in practice, large-impact, high- risk deployments end up happening infrequently

    due to understandable fear unfortunately, this means that our changes build up between releases 2015: Building Microservices * book published February 2015
  25. the bigger the delta between releases, the higher the risk

    that we’ll get something wrong! * book published February 2015 2015: Building Microservices
  26. throughout the book, I promote the need to make small,

    incremental changes one of the key drivers is to understand the impact of each alteration * book published February 2015 2015: Building Microservices
  27. 2015: gilt.com * QCon London, July 2015 simpler and easier

    deployments and rollbacks Yoni Goldberg teams can decide when they want to deploy deploy multiple times per day
  28. 2015: gilt.com * QCon London, July 2015 database schema changes

    are required to be incremental Yoni Goldberg database schema changes are released separately from service code
  29. 2016: Instagram * SREcon, April 2016 Michael Gorven https://www.youtube.com/watch?v=XNJ30Vy5xSg

  30. 2016: Instagram * SREcon, April 2016 Michael Gorven https://www.youtube.com/watch?v=XNJ30Vy5xSg

  31. 2016: Instagram * SREcon, April 2016 Michael Gorven https://www.youtube.com/watch?v=XNJ30Vy5xSg

  32. * book published June 2016 2016: Microservice Architecture reducing the

    size of the deployment unit a notion we call “batch size reduction” reducing the size or scope of the problem
  33. emphasis on small batch sizes 2016: DevOps Handbook the principle

    of small batch sizes also applies to code reviews * book published October 2016
  34. the heart of doing evolutionary architecture is to make small

    changes * book published September 2017 2017: Building Evolutionary Architectures
  35. an architecture that allows small, incremental changes is easier to

    evolve because developers have a smaller scope of change 2017: Building Evolutionary Architectures * book published September 2017
  36. with improved engineering practices comes decreased risk 2017: Building Evolutionary

    Architectures * book published September 2017
  37. * second edition, published January 2018 designing for deployment gives

    you the ability to make large changes in small steps 2018: Release It!
  38. * second edition, published January 2018 to be successful, your

    software will be deployed early and often smaller, easier deployments mean you can make big changes over a series of small steps 2018: Release It!
  39. 2018: Accelerate * book published March 2018

  40. * tweet, April 2018 https://twitter.com/bridgetkromhout/status/983739341074845697 2018: Bridget Kromhout

  41. 2018: Michele Titolo Microservice deployments should be small. If you

    have small services, you are probably making small changes. * QCon New York, June 2018
  42. 2018: Michele Titolo One of the benefits of small changes

    is that you can release frequently * QCon New York, June 2018
  43. 2018: Flow Commerce * QCon New York, June 2018 Mike

    Bryzek
  44. 2018: Flow Commerce * QCon New York, June 2018 Mike

    Bryzek
  45. 2018: Charity Majors https://charity.wtf/2018/08/19/shipping-software-should-not-be-scary/ * published August 2018 suffice it

    to say that we now know that smaller and more frequent changes are much safer than larger and less frequent changes ship early, ship often, ship smaller change sets
  46. 2019: Financial Times * QCon London, March 2019 https://www.infoq.com/presentations/microservices-financial-times Sarah

    Wells
  47. 2019: Jez Humble * tweet, March 2019 https://twitter.com/jezhumble/status/1106297185119797248

  48. Make It So small batches of work frequent deployments