I've read How Do You Pull Something from a Release?, but it doesn't solve our problems, as our case is more complex.

Our situation is as follows. We're developing an application for an internal customer. We're doing Scrum with four more or less aligned teams (i.e. sprints end on the same day), one of which is off site.

We have a basic DTAP street and we use Subversion for source control. We want to deploy to the TAP-end of the street from source control, as a preparation to use continuous integration later on. To be able to deploy from source control, we maintain branches that are in sync with each of the T, A, and P environments.
Our current setup is a clean trunk, which is in sync with Production, an acpt branch that was branched from trunk at some point in the past and which is in sync with Acceptance, and a branch for each sprint that branches from the acpt branch at the start of each sprint and merges back into it at the end. This sprint branch is in sync with the Test environment for the duration of the sprint.

At the end of each sprint, issues that are done are merged into acpt. A new sprint branch is made and a new sprint begins. Meanwhile, the acpt branch is deployed to Acceptance and tested there. Of course, in an ideal world, we would complete all user stories during the sprint and during UAT there would be no defects found. But alas, this world is not perfect and problems are found during UAT. Of course not bugs, but we may have interpreted a request incorrectly. Or there may be some other reason for a user story to not be released (yet). So now we have to pull some stories from that branch. Since the changes were merged from sprint branch to acpt branch in one go, this is not a trivial task.

How can we adjust our method to allow for user stories to be pulled from the acpt branch?

I've also read Agile version control with multiple teams by Henrik Kniberg. That looks like a model that's better suited to our needs, but even then I have some questions about it. If we adopt his model, should we sync the trunk to Acceptance? That would give us opportunity to conduct UATs during a sprint, and would effectively uncouple the sprint schedule from the release schedule. But Kniberg promotes a stricter adherence to Scrum than we currently follow, where user stories are done pretty much in sequence.

How could we adjust Kniberg's method to suit our needs?

  • 1
    syncing trunk with production sounds like wrong way. "The problem is you are changing what the meaning of a branch is part way through the process..." Get the meanings of your branches straight, stable and focused on a specific purpose
    – gnat
    May 14, 2014 at 14:50

2 Answers 2


In a past job we had a similar setup (DTAP) though we did not use SVN (we used Perforce) it would have been easily ported since both are or the same VCS family.

We had a development branch where all development occurred. Since branching is fairly costly in P4, same holds true for SVN we did not use sprint branches, only when a feature, or user story, or epic would be complex enough and would stretch in time long enough would we use a purpose branch from Development (trunk). It would then be the responsibility of the devs in this specific branch to keep it in sync with trunk and merge it back when done.

We had continuous delivery that would periodically take the trunk and build the product, I say periodically since the build took a sizable amount of time so we could not do it on every commits which would have been ideal.

A first line of QA (smoke test) was done on one of these trunk versions and if satisfactory the build was "promoted" to testing where it would undergo more intense testing (your T phase). We lazily branched to testing branch if testing did not reject the build (as too unstable) but still required fixes. Fixes were made in testing branch and merged to trunk and the build system would issue a new testing version. Rarely we fixed bugs in testing, preferring to continue working in trunk ans simply promote a later build. We fixed bugs in there when trunk was too unstable and/or fixes/features could no longer wait to be pushed to production.

Once testing got a pass, the build was again promoted to acceptance (in our case it was play test sessions, usability labs etc). The same process repeated as with the testing phase. Bug fixes made in acceptance branch were merged back to trunk (not testing, at this point the testing branch would most likely already be trying a new smoked tested build). When accepted again it was promoted to production.

In production however we eagerly branched everything from acceptance, promoted the build. Once promoted the build was immediately deployed. Should blocking bugs be found in the production line fixes were made there and (after the merge to trunk) built and deployed asap with minimal testing. Sounds a bit crazy with the minimal testing in prod that's because only a very small set of fixes (the ones that absolutely could not wait) would be done there, otherwise they got done in the trunk and went through the whole process.

Worked pretty good for us.

Now, to adapt this to a iterative agile process (SCRUM) there are many approaches that could be taken,

  • Promote at the end of the iteration only. Drawback is that production would always be 3-4 full iterations behind. That said, oftentimes it's the time the code needs to get properly stabilized and tested.
  • Promote continuously (as we did) and aim for a full cycle in one iteration. This is stricter adherence to scrum in principle. You get less done as you must allow for the testing. Drawback here is that while testing is underway you might end up having idle devs as they have finished their work and are just waiting for bugs to be found.

From experience I would try a hybrid approach. Promote to testing continuously and aim for promoting to acceptance at the end of the iteration. In your iteration planning see what needs to be fixed in acceptance and prioritize accordingly, aiming for production at the end of that second iteration. Your devs would have to split there time between two branches (trunk and acceptance) with the occasional foray in testing. This maximize productivity while minimizing the time to production.

  • trunk is the leading edge of your system, most unstable.
  • testing is a snapshot of trunk if bugs were found. Prefer fixing in trunk it at all possible though.
  • acceptance was where things got stabilized, more testing done here.
  • production was what was currently deployed. Rarely ware fixes done here but important to have nonetheless.

We did not have multiple versions in production, forcing users to update whenever a new production build was made.

Hope this helps, sorry for the novel, did not have time to do shorter.


Maintaining many branches in subversion is a drag, try git. Treat each build as a release candidate, and 'stop the line' for defects. Build binaries once. If you apply the principles of continuous delivery, like working with small batches, short-lived branches, integrating on the mainline, then your whole CI tooling becomes much simpler.

  • 1
    I'm with another company now, but we had to use Subversion. We wanted to move to Git, but that was not a short-term option.
    – SQB
    Feb 20, 2016 at 19:14
  • 1
    one does not always have the option to use git. Plus there are many cases where git just can't cut it. With large binary files for example, or very large source tree. I worked with TB sized source tree that were 10+ years old. Granted it was not the best layout and could have better been served by splitting it in multiple separate projects. The refactoring costs of this split alone were prohibitive.
    – Newtopian
    Apr 20, 2016 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.