
It’s a very simple pattern. Make a Continuous Integration build for the trunk and the release branches. Most projects don’t need anything more clever than this.
Blogroll
Popular posts
Useful links
Meta
Categories
- .NET (7)
- Build (51)
- Comics (4)
- Conferences (15)
- Continuous Integration (110)
- Deployment (13)
- DevOps (3)
- eXtreme Feedback Devices (16)
- Java (15)
- Jobs (8)
- News (156)
- links (125)
- Opinion (5)
- Patterns and Practices (23)
- Ruby (7)
- Site Admin (10)
- Systems Administration (11)
- Tools (5)
- Uncategorized (25)
- Version Control Systems (7)
- Video (7)
Job Board Menu
-
Home
Jobs
-
Sr. Systems Engineer/ Devops
at Threadless
Location: Chicago, IL -
Integration/Configuration Engineer
at Eloqua
Location: Vienna "Tyson's Corners", VA -
System Administrator / Devops
at Opera Software
Location: Melbourne, VIC, Australia -
Devops / Sysadmin
at onefinestay
Location: London, United Kingdom -
Devops Engineer / Build
at Gemvara
Location: Boston, MA
-
Sr. Systems Engineer/ Devops
at Threadless


4 Comments
We’re at most one release ahead of production, so we just have HEAD and the immediately prior release to run tests on; one of our projects releases frequently enough that we don’t even have to branch it at all normally. The three projects share a server farm, with several CruiseControl instances running different types of tests for each in rotation, so we’ve just inserted the branches as new projects in the rotation.
Since changes to the branches are rare, other projects don’t often have to wait for the branches. Since changes are well-vetted, we don’t run branched code through all the steps in the build pipeline, just the ones that are most critical (we skip browser-compatibility tests for example, since we rarely make substantial HTML changes in branches).
I totally agree! KISS rule goes a long way here.
I wrote a little bit of ant/shell to handle automatic svn tagging based on whether a build was run against trunk or a branch.
I can't post the antscript here (blogger paranoia!), but suffices to say it's pretty noddy. Just passes in the ${label} and ${checkoutdir} for the build.
The bash bit:
#!/bin/bash
# Expects to be called by the tag.xml antscript. Needs to be told the working copy it's tagging from and the label to tag with.
checkoutDir=$1
label=$2
svn_revision=`svn info ./${checkoutDir}|grep "Revision:"|awk '{print $2}'`
svn_url=`svn info ./${checkoutDir}|grep "URL:"|awk '{print $2}'`
echo ${svn_url} |grep trunk > /dev/null 2>&1
if [ $? -eq 0 ]
then
svn_tag_url=${svn_url/trunk/tags}/trunk/
else
svn_tag_url=${svn_url/branches/tags}
fi
echo "svn autotagging ${svn_url} at revision ${svn_revision} for build ${label}…"
svn copy -r ${svn_revision} ${svn_url}/ ${svn_tag_url}/${label}/ -m "cruise: Autotagging for build ${label}(Revision: ${svn_revision})."
echo "svn autotagging complete."
I'm sure there's a more elegant way to do it though
Branches? Unless its a transitional release (rc1, rc2, etc.) shouldn’t you be releasing tags?
Douglas, Jon. Thanks for your comments. I think I want to do a longer post on this topic.
Tea42: Yes, tagging/labelling is necessary to identify the exact code that’s running in prod. But IMO you need a branch so you can only release production bugfixes and enhancements and not mainline development as well.
One Trackback/Pingback
[...] September: Branching: do it like this and nobody gets hurt [...]
Post a Comment