29 Jan 2012, 00:18

Raymond Van Eperen (1 post)

I have for years been a subscriber to the practice of development in the trunk, and branch for release. However, as I have implemented some process changes in order to better suit our development environment, I am finding that to be quite challenging, and want to solicit some feedback around the pros and cons of my current thinking. A brief description of how our development works. We are supporting a system which is 90% legacy code. We are mainly doing bug fixes and enhancements. The system is quite complex, and that is exacerbated by the fact that the code is fairly tightly coupled - no it’s from before my time, but yes we are working on it :) - so sometimes even simple changes affect large areas of code. It is typical for a new feature to take a lot of back and forth with users before the right solution is determined - so knowing which release it will go on is almost impossible for all but the smallest tasks. We code and test a little, demo and repeat. For this and a number of other reasons, we have implemented a process that is analogous to a bus schedule. The bus leaves every two weeks - or in other words, we release every two weeks. Anything that is at the bus stop in time goes, and we usually don’t know what items that will be until shortly before the release date. So, my thought was that we create feature branches for anything except a small bug fix or enhancement that we are very confident will go with the next release. Once a feature is completed, and assigned to the next release, we merge or reintegrate it back to trunk, and when all items are there, we create the release branch and continue on. Otherwise we are left to create a release branch from the trunk which contains everything being worked on, and somehow pick out only those items that are ready to go (which would typically be only a minority of the items). As I stated at the beginning, this is not how I have worked in the past, but weighing the pros and cons given our circumstances, this seems to be the best approach. And curiously, my team is split on which way would be best, so I really need some sound advice in order to help us make a decision the team will all embrace.

  You must be logged in to comment