You are not. The conclusion of the article is the same, you "need to expand the far end of the hose" by increasing deployment rate or making more, smaller changes. What was your interpretation?
My reading was that there were two paths the author highlights:
1) Increase deployment capacity (which I'm reading as frequency, and I fully agree with)
2) Increase change capacity per deployment by making it less likely that a set of changes will fail through tests, monitoring, structural, and team changes
#2 is very much geared to "ship more changes in one deployment" which is where my disagreement lies. I think you should still do all those things, but that increasing the size of the bundle is explicitly an anti-goal.
I think you're better off, as a rule of thumb, making fewer changes per deployment if you want to reduce risk.
ricardobeat|1 year ago
sourceless|1 year ago
1) Increase deployment capacity (which I'm reading as frequency, and I fully agree with)
2) Increase change capacity per deployment by making it less likely that a set of changes will fail through tests, monitoring, structural, and team changes
#2 is very much geared to "ship more changes in one deployment" which is where my disagreement lies. I think you should still do all those things, but that increasing the size of the bundle is explicitly an anti-goal.
I think you're better off, as a rule of thumb, making fewer changes per deployment if you want to reduce risk.
But -- that is my particular reading of it.