It’s come to my attention that many people think continuous delivery/deployment is about taking whatever crap you have in version control & shipping it into prod as fast as possible so you can test in prod

NO

CD is about making it SAFE to ship your code into prod quickly by:
* Running many kinds of comprehensive tests fast & continuously so you find problems *before* you ship
* Creating a fast & reliable deploy process
* Working in small batches
* Evolving sociotechnical systems that let you rapidly detect, remediate & learn from prod incidents
This is hard and expensive and if you can’t do it you shouldn’t be building distributed systems.
There’s a reason the subtitle of the CD book was “RELIABLE Software Releases through Build, Test, and Deployment Automation” not “Test in production YOLO!”

BTW the CD book, despite being written in 2010, is still mostly true and is on special offer through Saturday the 16th
Of course things have changed significantly since 2010, and there's a free, comprehensive and evidence-based set of resources at devops-research.com/research.html. Check out the links to the >30 capability pages at the bottom of this site, or go to cloud.google.com/architecture/d…
There's a ton of material here. If it sounds like a lot of hard work, it is. But again, if you're not prepared to put in the work, you shouldn't be building distributed systems. Even *with* all this stuff in place, it's still really hard to operate distributed systems!
Some clarifications:

* Testing in prod is great, you should absolutely do it! It is not an _alternative_ to these practices, it's something these practices enable.
* What's the difference between continuous delivery & continuous deployment? Continuous delivery means you _could_ do continuous deployment if you wanted to, but it doesn't make sense (e.g. for app store apps / embedded systems / medical devices). The practices are all the same.
Also, if video is your thing, my esteemed co-author of the CD book, @davefarley77, has a fantastic YouTube channel: youtube.com/c/ContinuousDe…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Jez Humble

Jez Humble Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jezhumble

4 Aug
Everyone sensible in IT has been saying for years that if you buy COTS (commercial off-the-shelf software packages) you shouldn’t customize it - it’s wildly expensive and you end up with something hard to maintain and almost impossible to upgrade.
COTS is for business processes that aren’t strategic to your org. So you should MODIFY YOUR BUSINESS PROCESS TO FIT WHAT THE SOFTWARE DOES OUT OF THE BOX! Sorry for shouting, I’m old.
So imagine my surprise upon learning that the FAR (federal acquisition regulation, which governs how agencies buy things) prohibits you from significantly customizing COTS! But agencies DO IT ANYWAY!!!
Read 9 tweets
26 May
Just to get this off my chest, sometimes people look at the DORA research & say, "correlation doesn't imply causation."

We were careful to say which results are correlations vs predictive inferential. The arrows on the diagram on this page are the latter: devops-research.com/research.html
In Chapter 12 of Accelerate, @nicolefv describes the six levels of statistical date analysis in Dr Jeffrey Leak's framework:

1. Descriptive
2. Exploratory
3. Inferential predictive
4. Predictive
5. Causal
6. Mechanistic
Randomized, controlled experiments (like A/B tests) are cool because they demonstrate a causal relationship - although my friend who is a research scientists complains RCTs are not real science because they don't tell you anything about the causal mechanism, in other words: why?
Read 6 tweets
4 Oct 20
OK apparently this still needs saying:

1. SOX does not mandate segregation of duties. Neither SOX section 404, nor the SEC rules for implementing SOX. Image
2. Segregation of Duties is a good control to implement anyway, and is required by the NIST RMF (for implementing FISMA) and PCI-DSS, for example. However it *does not* prevent developers from accessing production, or deploying to production.
3. Attached is a case study from a few years ago on how Etsy meets PCI-DSS and has devs deploy to prod, with some wider lessons (from Lean Enterprise, pp242-243). ImageImage
Read 8 tweets
13 Aug 20
We've just launched new #DevOps content at cloud.google.com/devops today! There's an updated quick check to recommend which capabilities you should work on, and write-ups of new capabilities from the State of DevOps Report. More here: medium.com/@jezhumble/tak…
The quick check tool now recommends capabilities to prioritize in order to improve your performance against the four key metrics: devops-research.com/quickcheck.html Image
There's a new homepage for the DORA research program where you can explore the capabilities we've identified that drive improved performance, read State of DevOps Reports, and see solutions for many of the capabilities we've identified: devops-research.com/research.html
Read 13 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(