Hi!Since I set out to develop Buddy Blip I’ve been using continuous deployments to publish code changes for the public facing website. I really like this methodology, but the concept can be quite frightening at first.
For a typical deployment the team would set up a timeline/milestone to get bug fixes and new features deployed to live. This is a nice practice as it allows you to smoke test significant changes, however one thing I’ve noticed is that a portion of your team has now “forked” off to handle the deployment and they are no longer working on features. Depending on the scope size of the milestone, a good portion of time would be taken up by one or more people to prepare and execute the deployment. I’ve seen cases where this is limited to 30 minutes of work for 2-3 people, but I’ve also seen that this take an entire dev team a full day to synchronize code to a release branch (and tag) and deploy it.
When using continuous deployments for deploying web applications the process typically takes 5-10 minutes for a single developer. For me the process is checking in my code to the trunk, making a branch from the latest release, merging my changes to the branch, tagging the branch as a release and then deploying the code to live.
I still like to maintain the “trunk” as a progressive development version so I set up a branch and only merge in the changes I want to deploy to live. This is so I can maintain and back up versions of code that aren’t ready for live yet. For significant development changes that would take multiple weeks I will typically branch off of the trunk, but for small features that only need a few days of work and testing I will continue to work off the trunk.
In all I like the continuous deployments, however I’m curious to see how well the methodology holds up as the team grows and scope increases. However I feel if the scope increases then I’m no longer practicing Customer Development/Lean Startup methodologies.
My observed benefits of Continuous Deployments
- Morale is increased due to momentum of getting things done
- Quicker route to testing new ideas with real users
- Focus on obtainable feature sets and things that matter
