Introducing a version control branching policy to a small team

Question

I'm a contractor that has recently started with a firm.

Team is 3 developers consisting of 2 junior to mid level devs, with another at the same level starting soon, and myself (6 Years xp). For both the existing developers it is their first job out of university/college, and they've never had a senior developer overseeing their work before.

There is no explicit Version control policy. Developers do all the development on the trunk and then deploy to production direct from their development machines. The existing team are not familiar with branching.

I'm changing all this and introducing CI, TDD test/staging/production servers etc, along with a version control policy to compliment this.

Source control system is TFS, which i've never used before. It's configured as one giant repository.

I've written down a few pointers for them, but is there anything else i should be adding/ amending, bearing in mind the experience of the team?

Version Control Policy

Development is done on the trunk

If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.

Release branches created for production code. That branch should only contain stable code. We can either have one release branch that gets updated from the trunk once per sprint, or we can make a separate release branch for each week.

If a urgent bug fix affecting production code needs to be made, then it gets made on the release branch, and merged back into the trunk.

If we adopt the one release branch strategy then the trunk gets merged into the release branch once per sprint towards the end of the sprint.

If we adopt the seperate branch per release strategy, then the trunk NEVER gets merged into the Release branch

In some scenarios it may be necessary to make the bug fix twice on different branches, if branches have diverged too much. If we are doing short sprints then this shouldn’t happen too often.

---

I plan to have three servers. Test environment that is always running the latest code in the repo. A staging environment which is running the newest release candidate for staging/testing Release Candidate code and UAT purposes, and the production environment.

The reason why i plan to do this is that so far the client has only done internal software. The newest project is for a high profile media client, and my feeling is that the team need to adopt a more professional development model than what they do at the moment.

For example at the moment, a user may phone up the team with a bug report. The devs locate and fix the bug, do a quick test eyeball test on their own machines and then deploy straight into production. No automated testing or anything.

---

In hindsight i think the feature branch is a step too far and i'll remove that.

So essentially it comes down to a) no branching at all) b) a release branch and the trunk, and c) a release branch per release and the trunk.

I was leaning towards the latter. My initial thought would be that i would have both a release candidate and a release to be live on separate servers(UAT/Production) at the same time, but effectively the trunk is the release candidate at any point in time, so a branch per release is leaning towards insane. My only thought would be if we didn't want our stakeholders to see development code then we might need a separate release candidate branch, but YAGNI and all that.....

Answer 1

For a team of 3-4 devs, you're proposing WAY too many branches.

Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost.

Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated.

Having a separate release branch for every sprint is insane. Why do you need the code from one sprint isolated from the code for the next? Why not just have a single stable release branch that gets carried forward with each sprint?

If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.

Almost any non-trivial new feature is going to take at least a week in real time after you account for development, developer testing, daily interruptions and other activities, etc.

Also, what's a "regular merge"? Daily? Weekly? Every merge you do takes time - you need to make sure the target merge branch builds & runs after your changes. On a small team, frequent merging is a lot of overhead.

We have a team of 4 developers working on a 1+ million line codebase and this is how we operate:

• Main branch where all development is done
• One branch per major release (done about once per year)

The one major rule is: don't check in code that doesn't build.

That's it. Simple, easy to understand, gets the isolation we need (at any time we can create a release build for any version).

The upsides to having all development work done on one branch:

1. Developers are always in-sync with each other. No painful merges because two developers were off on their own branches for weeks creating incompatible changes.
2. Broken builds are found on the same day. We have a nightly build that runs the latest code on main. If someone does check in code that doesn't build for some reason, we will know right away.
3. With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
4. No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.

Answer 2

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team members who will try to do whatever they can not to apply your concepts.

Do they have a problem which needs to be solved? It's crucial to answer this question first, because either they actually do have a problem and will welcome your suggestions, or they are perfectly fine working as they currently do, and you are just pushing at them your way of working, just because you prefer to work this way.

Eventually, forcing them to use branches can have an extremely negative impact. Working with a trunk is easy, especially in Agile environment. A developer commits changes to the trunk, eventually handling small conflicts, and those changes are immediately used by Continuous Integration platform. With branches:

• A developer has to think where should the change be located,

• Somebody has to manage branches and merges from branches to the trunk,

• Merges between branches are done less frequently than commits, which means that somebody has to deal with conflicts which are larger and more difficult to handle than a conflict between two commits,

• Every commit doesn't find necessarily its way into Continuous Integration, which delays the information the developers get about the effects a commit can have (especially regressions).

The fact that:

The existing team are not familiar with branching

makes things even worse. I worked in a team of inexperienced programmers, where an inexperienced manager decided to play with branches. This resulted in a lot (a lot) of wasted time and is exactly the thing you want to avoid for a project which has deadlines.

Answer 3

Like Mainma says, be careful with the branching. You mention branching every few weeks, is it really necessary to have a lot of branches?

Alternatively, you could also have a 'pull' model instead of a push model. If you were using Git or Mercurial, you could have an integration server validate their changes before pushing to the central server. In TFS, you can do something similar using gated check-ins. This way, you can have validation and avoid the complexity of branches.