Some time back I came across an article “5 things Amazon taught me about deployment automation.” It does not say anything radically new, but gives some good examples of why deployment automation (including quality automation) is good. Oh, and this is *nothing* about how Amazon does deployment automation – they just use the end-user Amazon experience as parallels to deployment automation.
“When you make [deployment] cheap an easy … you change behavior in radical ways.
- …There’s a surprising difference between having a web page where someone can easily request a deployment and automatically deploying to test as the result of a new build or a nightly schedule. On event/schedule gets has a bigger impact over self-service… this helps turn CI into CD
- It’s about effort, not speed. [Making testing easy is more important than making testing fast … most of the time]
- When deployments are a big, scary ordeal teams set up release weekends and release trains where numerous projects go out in a big effort. With automation … when something is ready to ship, it goes out. It doesn’t wait for a bunch of unrelated other projects to make a release weekend worthwhile.
- … Because rollbacks allow us to reconsider more easily, they enable us to be more aggressive in releasing (even to just test environments).
- Do things the “right” way… Make it easier for people to deploy following protocol than to work around the system.”
I think the full article is a worthwhile quick read as a reminder of some of the little (and may be not so little) benefits of automation. I include the Stratus and QE visions as a part of this.