So I went along to the ThoughtWorks quarterly update on Continuous Delivery today. This took the form of a panel discussion with Martin Fowler, Evan Bottcher and Neal Ford. Smart guys, interesting topic and tantalising banner ad:

The good news is that I didn’t hear anything that sounded too foreign. Either they were principles I’d written about, experienced firsthand or at least had a good understanding of. Usually it was all three but hearing the words from these guys in a very candid fashion is a great endorsement of the beliefs.
Here’s the “best of the best” in terms of the messages that really resonated with the crowd:
- Software that is not automatable is broken.
- Not being able to reproduce a production environment on demand is extremely risky.
- Get the computers to do the low value, automatable things (i.e. deployments) and let the humans focus on the high value work.
- If it hurts, do it more often (i.e. build and deploy).
- Any time a dev executes a repetitive task manually, all the servers get together late at night and laugh (always wondered why they looked so damn smug each morning).
- Everything – EVERYTHING – that is required for the app to be built and deployed must exist in source control.
- Get used to pushing into production regularly, it takes away the fear.
- Far too much emphasis is put on “it’s looking good” and “code complete” (downplays the risks yet to be faced by deployment).
- Every time you’ve done something for the third time, automate it!
- No test should remain un-automated that could be automated.
- Once you start automating, you find all sorts of ways of doing it better.
- Start pumping lorem ipsum text into change scripts and see if anyone notices (funny, I found a “If you are reading this I will buy you a coffee” statement in a standards doc last week; apparently I was the only one to spot it in the last year).
- Smells – sysadmins manually logging onto servers installing patches, prod server being thrown out the window (deployment to new one should be mundane), trying to “fix” an environment rather than just re-deploying.
Want more continuous integration and deployment goodness? Try these:
- You're deploying it wrong! TeamCity, Subversion & Web Deploy part 1: Config transforms
- You're deploying it wrong! TeamCity, Subversion & Web Deploy part 2: MSBuild and deployable packages
- You're deploying it wrong! TeamCity, Subversion & Web Deploy part 3: Publishing with Web Deploy
- You're deploying it wrong! TeamCity, Subversion & Web Deploy part 4: Continuous builds with TeamCity
- You're deploying it wrong! TeamCity, Subversion & Web Deploy part 5: Web Deploy with TeamCity
- Continuous code quality measurement with NDepend and TeamCity
- Continuous project statistics with StatSVN and TeamCity
- Continuous web application security scanning with Netsparker and TeamCity
- Automated database releases with TeamCity and Red Gate






Software architect and Microsoft MVP, you’ll usually find me writing about security concepts and process improvement in software delivery.





3 comments:
Thanks for the great summary! Really enjoy reading about this subject and need to follow the links through as well. I was wondering - are folks solving the ongoing patching updates using automation? Patches consume a major part of the weekend each month. Seems that automating that would be a great savings. Just curious if you have any experience/thoughts around this?
regards,
Bill44077
Hi Bill, I was actually wondering exactly what context they referred to patches in. If we're talking OS level, many organisations obviously already have patch management tied up as part of their data centre management strategies. Was the context perhaps around aligning patch levels with the expectation of the apps under CI?
But I assume they're not referring to patches for the app itself otherwise this would be handled as part of the continuous delivery cycle.
Thanks for the great summary! Really enjoy reading about this subject and need to follow the links through as well. I was wondering - are folks solving the ongoing patching updates using automation? Patches consume a major part of the weekend each month. Seems that automating that would be a great savings. Just curious if you have any experience/thoughts around this?
regards,
Bill44077
Post a Comment