svn deployment strategies for multiple groups of developers (not co-located) working on different components of the same project

Question

Our project is a content management system supporting several dozen of our websites. The development group started off small and in one location, and we dealt with a fairly

Answer 1

I'm a big fan of continuous integration along with test driven development.

Here's some links I'd recommend checking out:

• CI from wikipedia
• CruiseControl
• Xinc - CI for PHP (my fav, it's simple)

Answer 2

Combined maintenance- and release-branches

I think you are having similar requirements like our people. A CI would help you automate but it does not solve the underlying organisational challenge.

So you have 2 types of checkins:

• normal non-urgent code (slated for release every once in a while)
• urgent "hotfixing" code (happens after a release if something slips through without enough testing or when customer X calls because he wanted the button pink not purple and he threatens to drop the contract :P)

Both cases are different and you need to seperate them. Your approach is allready close to an answer I think but you are doing "too much"

Let me describe you what we do:

Repository Layout

trunk (is our project with components and all)
branches
|
-- 1.0-stable-week-40
|
-- 2.0-stable-week-42
|
-- 3.0-stable-week-44
tags
|
-- 1.0.0
|
-- 1.0.1
|
-- 1.0.2
|
-- 2.0.0
|
-- 2.0.1
|
-- 3.0.0

As you can see we have a trunk for all the main development work. We also create stable branches for release preparation and testing every 2 weeks and we tag all releases when they go live.

Release lifecycle (generalized)

After a new release we maintain the branch (1.0 for example) until the next major release is pushed out. Our policy is that during that time ONLY critical fixes may be checked in to that branch. They go through minimal testing only and can be released in a matter of minutes by creating a new tag from our maintenance branch.

Halfway through the maintenance period (1 week after the release) we create a new branch from our trunk called "2.0". All not-so urgent development allready in the trunk will be in this release automaticly. More things can be added "carefuly" like urgent fixes that come from the currently active maintenance-branch (merge from 1.0 to 2.0 to trunk).

After another week passed and all testing was done the 2.0 branch gets tagged as 2.0.0 and released, given no major problems arised. The 1.0 maintenance-branch will be abandoned and deleted eventually.

This way we can seperate urgent from non-urgent changes and have relatively pain-free and stable releases. What you do is pretty much the same but you branch from a tag which when you'r finished you tag again. Thats a bit much :). Branching from tags is also bad style. branch from branches.

---

branch policies

It helps the team if you write down the policy for each of your branch-types enabeling them to do more on their own without having a release-guy constantly sitting in their neck and luring over their commits ;)

Our policies could be described this way:

• trunk:

  • no commits with syntax errors
  • receives merges from maintenance
  • no direct releases from this branch

• branches/X.X-stable

  • may receive urgent fixes only
  • should be "release-ready" at all times
  • developer MUST merge down his commit from here to any younger stable branch
  • If no younger stable branch is available merge to trunk

• tags/*

  • No commits here
  • used for deploy

Merging becomes also less of a mind-training once you try to merge into one "direction" only. (You might want to google for the tofu scale but thats getting a bit OT now ). See that merges are done continuously by developers and not release managers to limit the bottleneck. While one release is live and actively maintained receiving hotfixes, we allready start to prepare the next, isolating it from possibly unstable changes in the trunk and giving it time to "ripe".

You might have different requirements for the duration of code-incubation and testing or length of release iterations of course. Adapt :)