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.
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
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
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
* 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
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
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.
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
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
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
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
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
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
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
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
* 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
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
* 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!
2018: Michele Titolo Microservice deployments should be small. If you have small services, you are probably making small changes. * QCon New York, June 2018
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
sullis
assu_ming
clown0082
kamilahsantos
mot_techtalk
akkyie
zakky21
skanehira
mugi_uno
chimame
kasacchiful
syukai
philipschwarz
jcasabona
aarron
wjessup
frogandcode
deanohume
addyosmani
mthomps
destraynor
jlugia
speakerdeck
productmarketing
akmur