SVN structure for deploying features and fixes to test and production in any order

Question

The situation

For example purpose, the following situation can be considered:

• Feature A is a big one, multiple days of work. At this time, it's not yet coded but nearly so. Should be released for testing as soon as done. Considering the size of the feature, development is likely to stretch for some more time after that with some back and forth between development and testing.

Everything below has happened since the beginning of Feature A:

• Fix B came up during , coded quickly, but testing takes a long time (depends on another busy team), not yet finished, not ready for production.
• Feature C is introduced. Quickly coded but results uncertain (may require multiple commits through time to reach the final version). Testing of current state in progress. Results may lead to code adjustements. Meant for production at a specific date in a few months, not before.
• Fix D, quickly coded, is in testing and is very likely to be ready for production before Fix B and Feature C.
• Fix E is more involved, might take a few days. Multiple commits are expected. Should be testable along the way. It's unclear when this will be ready for production.

We might end up having to put Fix D in production, then Feature C, then Fix B... but maybe it's going to be Fix D, then Fix B, then Fix E, then Feature C. And who knows, maybe Feature A will go smoother than expected and will have to be released before some of the other bits.

How would one deal with this many parallel developments in SVN and when deploying? I'd interested in what one would commit in which branches, what might end up in the trunk, and deployment steps when any of these is ready for production, knowing that in our environment we do not really feature-freeze anything and any fix or feature, if ready, is likely to be pushed to production (I'm not sure this is great either -- if you think this is the root of our deployment issues, do tell).

---

The context and current solution

Our team uses three environments: development, test and production. We use a SVN repository for the web application with the usual(?) structure: trunk, branches, tags.

Our current method goes like this:

• Develop on trunk unless it's a big new feature. This includes quick bug fixes, quick changes and things that are invisible to users (updates to dev-only features).
• If it's a big feature (multiple days of work or very risky change), create a new branch and commit there until ready. Switch working copy back and forth between the branch and trunk as needed.
• When quick changes are ready for testing, we simply svn-update the working copy on the test environment (it points to trunk).
• When a big feature is ready for testing, we usually switch the test working copy to the branch temporarily. This doesn't work well when two branches are to be tested at the same time.
• When things are tested and ready for production, the method has varied...
  • Production points to trunk and is simply svn-updated
  • Production is switched to a release tag
  • Production points to a production branch where trunk updates are merged with cherry-picking

While this has worked for a while, the current situation makes it rather unmanageable. There are at least 3 different fixes that were committed to trunk but need to be tested before going to production. Since development and test working copies point at trunk, all the fixes are available for testing (no problem there). There are also 2 branches that need testing before going to production. With the current method, they would need to be merged into trunk which is problematic if they turn out not to be ready.

A frequent situation is that bug fix A is ready for testing before bug fix B (and committed in that order in trunk) but bug fix B ends up tested first (client priority) and needs to go to production right away.

Oh and we don't have test suites on this application because it's a huge legacy codebase and there is not time alloted to creating tests. As such, committing to trunk "when it's done" is mostly based on gut feeling.

Answer 1

Sounds like you need to:

A) introduce release/integration branches:

• create a branch for the 'next release' from a trunk revision at which you are certain all changes at that point are ready for release.
• test against the release branch
• 'hotfixes' can bypass this branch (see below)
• new features and trunk revisions can be merged or cherry pick merged into the release branch if required.
• once tagged and released, reintegrate the branch with trunk and delete it.

B) create Tags for fully tested releases

• Once the release branch is prod ready, tag it, and svn switch production to the new tag

C) create Hotfix branches for emergency fixes:

• create a hotfix branch off the most recent released tag.
• commit the fix
• tag it (ensuring the label indicates the released version is still prior to that 'next release'. Eg. If the next release is 1.1, and the hotfix was branched from 1.0, make the hotfix release tag 1.0.1