Version Control – Introducing Branching Policy to Small Team

development-processteam-foundation-serverversion control

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…..

Best Answer

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:

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.
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.
With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

Source Control: Roles and Responsibilities – Best Practices

My general take on the best practices is that any member of the development team should be able to perform any action on the tree presuming those actions don't do things like kick off a production deployment. In cases where a specific branch / tag / repository does act as a source for automated deployments putting in some reasonable change control or barriers to entry make sense, more from a keeping mistakes merely mistakes perspective than some control-freak angle. I would encourage developers to create branches and improve the build scripts. I would find ways to get developers access to production if needed. Part of the point of source control is it is an effective magic eraser of mistakes -- the worst you'll need to do is roll back a rev or two and branch off that.

Unfortunately this doesn't sound like the approach they have taken here. In order to defeat this I think you need to cover a few angles:

a) Prove that these policies are detrimental to developing things. Log all the time you spend waiting on ops to get working on something. This alone should sell reasonable management on why this is a bad policy.

b) Make some friends in Ops -- perhaps there is a reason for this policy. Perhaps that reasoning could be addressed in a more effective manner.

Hope this helps.

Best Answer

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

Source Control: Roles and Responsibilities – Best Practices

Related Topic