Continuous Deployment Immersion
I had this idea while I was sitting in the Startup Lessons Learned conference. You definitely don’t want to try this. It’s a crazy idea. And you don’t want to hire me to come facilitate. That would be piling madness on madness. Here’s what you don’t want to do:
Get the whole team in a conference room Monday morning. Choose a feature you are going to add. Have one person come up to the one machine in the room. Write one line of code. Deploy.
If you can’t deploy, erase that line of code and write a different line of code first. Deploy.
Once the deployment is done, write another line of code. Deploy.
About this time some of the rest of the team is going to be bored watching all the manual steps in the deployment. Have them go off and automate the most tedious, boring, or error-prone step. Bring the automation back to the conference room and start using it.
By about Wednesday you’ll be feeling pretty good about your ability to deploy (even if you aren’t feeling so good about progress working one line at a time). You’ll likely make a mistake. Roll back manually. Split off a team to be able to roll back automatically.
At some point you’re likely to need to change some existing code. If you don’t have automated tests for the current behavior, split off a team to write a test before changing the code.
By Friday afternoon you may not have made much progress on your feature (but you may be pleasantly surprised), but you will understand deployment much better than you do now. You will also understand how to slice development more finely and rearrange the pieces. You will also understand the value of automation.
But don’t do this. It’s a crazy idea. Never work. Forget it. Sorry to waste your time.