Whether you’re running your website from the trunk or a release branch, you’ve already taken the first important step – you’re using a source code repository. Depending upon the size of your team and website, the way you manage this repository will vary tremendously. I’d like to share some of my experiences in managing code repositories – a must-have skill set for agile web development.
Development branches vs. stable, protected release branches
Creating development branches has certainly become mainstream nowadays and there are plenty of articles out there which explain merging techniques. While I’ve heard a lot about stable, protected release branches like the Mozilla Foundation uses for Firefox, others often type cast the trunk into a “sand-box” role, open for any quick and dirty commits. For this reason, the trunk is commonly accepted as “bleeding-edge” – to be checked out and deployed at your own risk.
Why do we still do this? Does our inner cowboy still need some semblance of the open range – a dirty, dust-bowl of fleeting opportunities and lonely heroes?
Making the trunk our release branch
In order to send a wake-up call to these determined folks, we made a decision that fundamentally changed our development methodologies (and ultimately resulted in a far more stable website). We made the trunk our release branch and removed write access from everyone except senior developers involved in operations. Now, the only way to “play around” with the trunk was to make a branch and commit your work there. An unexpected side effect of this change was a greater visibility for what was being developed. Branches were being created on a daily basis with plainly written titles. It was much easier to get the context of a particular commit within a well named branch rather than the lone drop of water in the vast ocean of the trunk.
Keeping up to date with the trunk
Now that everyone is coding away in their branches, take care that these code bases don’t drift too far apart. The morning after a release is a perfect time for everyone to merge the trunk into their branch and ensure it still runs. In order to avoid stale development branches, we came up with a weekly cronjob that examined all branches for the last merge. If none were detected in the previous 2 weeks, the developer responsible for that branch would get a direct email with the entire team on Cc: (peer pressure works wonders).
Merging back development branches and releasing the trunk
When one of these development branches is ready, we prepare the release:
- Merge the branch into the trunk
- Ensure the build and tests all work
- Deploy the trunk on reference for integration testing.
- Releasing to production is as easy as deploying the HEAD revision.
Rolling this concept out within your organization may be a long, uphill battle. But, often true learning only comes by choosing the road not taken, which, in the immortal words of Robert Frost:
“Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.”
Agile Web Operations 