Niroj Dahal

A failed branching strategy in version control

Published one year ago 5 min read
image

While working on a big project , we used TFS for version control. We created branches for every single client for development and a separate branch for production that was branched out from development. Initially, everything went smooth but as the time passed, complications arised.

Initially there were only few clients. Development were done in Develop branch and was merged to master after testing the features/fixes in development branch. After the changesets were merged to master, they were then merged to respective client development branches , which would eventually be merged to production branch for release.

Everything went good until every clients needed modification as per their request and the requests were not similar. They would differ for each client. Application flow was similar but still calculations and other stuffs were differently requested.

Now, the database related dependencies needed to be merged from master to every branch so that the DB structure remained constant across all client branches.

We faced following issues because of client-specific changes

  • In order to push a minor fix to one of the client, we had to merge all database related dependencies until the needed changeset in checkin history. Merge cycle increased.
  • QA had to test every branches except production. First they had to test changes in develop branch and then would be tested in individual client branches as they had their own customization.
  • Release took time as most of the things were held up during testing cycle.
  • Noone had concrete idea about what customization were done for a specific client
  • Merging resulted in some unwanted changes pushed to a client or some must-have feature removed.
  • Another major problem that we faced was that we had to release too many changes as some changes had to be pushed because of dependencies. As such, we merged many fixes, changes and features in production from client's development branch. We would then release those changes in client's UAT server. But even if they gave green signal to push few or some of the changes from UAT server to LIVE server, we couldn't since all of the verified and unverified changes were merged in production.
  • If the UAT and LIVE server differed by a single release, we had tough time pushing the hotfix changes in LIVE server.

Because of all these complications of branching for each client, we had to think of the other way for branching strategy. We are currently focussed on trunk-based development for version control strategy.

Thank you for reading.