My team uses a Kanban style approach to development where feature and bug fix stories filter through to Production as and when they are ready. We currently are using SVN as our VCS and take a feature branching approach to developing each story. A very simplified version of our workflow would be this:
- Branch, develop story
- User acceptance demo of story from branch
- Reintegration to trunk, TeamCity build of package which is released to Test
- Into Production if all is well
However one issue that has come up recently is if we have a number of feature stories for the same application going through at the same time this can cause problems if one of those stories has a bug. So say story 1 was reintegrated and had a bug, but stories 2 and 3 were reintegrated before that bug was discovered. We now have 3 releases containing that bug which means we end up doing one of two things, neither of which are great:
- Create a new patch release to follow story 3, which means a large Production deployment as stories 1, 2 & 3 + patch have to be deployed as one.
- Rollback the trunk to the point of the bug being introduced in story 1, fix the bug, then reintegrate stories 2 and 3 and rerelease, which is a lot of work and open to manual error.
So my main questions would be:
- is it more optimal to conduct System testing on branches prior to their reintegration to head off this scenario? How about the risk that testing is not taking place on the true trunk code?
- or are there other possibilities given by the use of a more modern DVCS that we are restricted from trying by our use of SVN?