A couple of weeks ago, an interesting question appeared on the pm.stackexchange.com site about how to deal with defects across multiple development tracks when the development follows the iterative model. My answer was to introduce one-track in the way of working, and I promised to write a bit more about it.
The name one-track is a bit misleading. It means that there is only one branch - hence the name one-track - in the version control system, which the deliveries are made from. Of course, there can be other branches as well, but the changes must be merged to this particular branch in order to get them delivered. I’ll refer to this branch as master from now on.
We used to work like this:
We were working on the master branch and when we considered the new version ready, we delivered it and branched out from the master. From this very moment, the delivered version lived in its own branch: the small change requests, fixes and changes were done here, while the brand new ideas were developed on the master until the next delivery. This was a business driven concept: we wanted the customer to pay for the new versions, so we needed a model to keep the versions separate.
Maintaining a system like this was very expensive, and the costs were not always visible. Imagine that a critical error had been found in an old, but still supported version. The fix had to be done in every later version, and this meant that the developers had to merge the fix to each branch. I remember that once it took us three weeks to do this merging properly. Additionally, testers had to test the fix in each version, which took days. All this work for free, because fixes are part of the warranty in most of the cases.
Nowadays companies realize that the effort spent on merging and re-testing is a waste, and they have started to introduce one-track in their development processes:
In this model the branching out happens when the development starts, so the branches contain features not versions. When the new features and fixes are ready, they are merged back to master. Testers always take the latest revision of master and run their tests on it. In case they don’t like it, developers rollback to the previous revision which was working and continue from there.
With this approach, the customers will get all the features and fixes present in the actual delivery even if they don’t want to. The model doesn’t say that every time when a delivery is made all their customers should get the new versions, but it is recommended. I know two solutions for this issue. Either the company doesn’t care, because it has a business model which has nothing to do with features (e.g. SaaS), or the features are developed so that they can be turned on or off on customer request (e.g. licensing).
From the developers’ and testers’ point of view this a great model, because they have to maintain only one track/branch/version. However, from the management perspective there are still a lot of things to do. Most of the customers I worked with had no intention to install our latest version, I still don’t know why. Therefore, the management didn’t see the point in trying to convince them to change to this model. Now, in the age of cost reduction they know that the merging and re-testing is very expensive, so they are trying to find a way to sell the one-track idea to the customers, and fortunately they have made a pretty impressive progress so far.