Source Code Branching – Best Practices

In the earlier article we saw potential branching strategies. This article talks about best practices in branching source code repository.

Freeze Production Branches

When a particular code branch goes to production, that branch should be frozen. No more commits should be allowed to made on that branch. This practice would make accidental commits that developer would make to the branch.

Freeze/Unfreeze Process before entering to Production

When the application code has been stabilized and QA team completed it’s testing and ready to enter to production, that branch should be frozen. Once branch is frozen no developer would be able to commit the code to the branch. Only if some showstopper/critical bug fix has to be made, then branch will have to be unfrozen. Branch should be unfrozen only after the application lead’s approval. Application Lead will have to thoroughly weigh-in the risk of bug fix, before he approves the unfreeze request. In general last minute code commits, tend to destabilize the application, thus  they should be handled carefully. Any commits made by the developer should be thoroughly tested.

Besides that this freeze process would also prevent developers from committing the code accidentally to the old branch.

Deploy Check point as well

Create a file with the name to be the check point of the application code base. Say application code base check point is: be_2013_08_03_259, create a file that name or you can create a generic file like checkpoint.txt and this file’s content can contain the value to be be_2013_08_03_259. Deploy this file along with the application in to the servers.  In this way you will get visbility in to what check point of the code is deployed in to what servers.

In any organization there would be several environments: development, testing, staging, production. Besides that in each environment there would be several servers. Each server can contain different version of the application code. Deploying the check point along with the application would give clear visibility what environment and what server is running with what version of code. It helps to avoid several surprises.

Developers avoid dual commit

When there are more than one working branch, say be_2013_08_04 (active development branch) and be_2013_08_03 (branch that is already in production). If developers makes any bug fixes in be_2013_08_03 production branch, in several organizations he himself would be made responsible to commit those changes to be_2013_08_04 (active development branch). It’s advisable to have a separate merge engineer who merges the code from be_2013_08_03 to be_2013_08_04, instead of the same developer. Here are the advantages to this approach:

1. Developer himself is in a heat of moment to fix a production defect. He shouldn’t be overburden with additional tasks of merging the fix to development branch at that heat of the moment. Most of the time, developer would forgot to merge the fix due to the heat of the moment. Thus this bug fix, would never get propagate to next release 🙂

2. Sometimes several bug fixes has to be made in the production branch. Each bug fix would be made by different developer. In those case each developer would have to merge his fix to development branch. It wouldn’t be productive for each developer to merge his bug fix in to development branch, rather than one consolidate merge.

There doesn’t have to be a dedicated merge engineer. One of the developer in the team on a round-robin basis can act as a Merge Engineer for a time period (say 1 week or 1 month).

Automated Frequent Merges

It’s highly recommended to automate the merge process. Only in the event if there are merge conflicts and merge/developer engineer should be involved.

Also it’s recommended to do frequent merges from the production branch to development merge. Don’t wait till the end. More the time production bug fixes soaks in the new development branch it’s better for the application stability.