17

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

MrBliz
  • 513
  • 3
  • 12
  • 3
    did you consider adding an explanation of why you picked this way? say, similarly to how it is done [here](http://programmers.stackexchange.com/a/191194/31260). Also, did you check "Microsoft Team Foundation Server Branching Guidance" (referred eg [here](http://programmers.stackexchange.com/a/108298/31260))? – gnat Jun 16 '15 at 11:42
  • 3
    Try [this one](http://nvie.com/posts/a-successful-git-branching-model/) – gbjbaanb Jun 16 '15 at 12:01
  • 1
    Bear in mind that i'm using TFS not a DVCS like GIT. That seems a bit git specific. – MrBliz Jun 16 '15 at 12:44
  • @gnat, the simple programmer link is effectively the strategy i'm describing i think ? http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/ – MrBliz Jun 16 '15 at 13:07
  • 2
    The end of that link says: "Everyone works off of trunk. Branch when you release code. Branch off a release when you need to create a bug fix for already released code. Branch for prototypes." I would suggest that for a simple beginning you just tag releases when you are reasonably sure they are Done. Unless you have multiple developers working on multiple features there is not much need to have more than 1 branch. Everyone adds features, everyone fixes the release candidate, everyone agrees when it is ready to tag. That means you only have to hand branches for bug fixes later on. – TafT Jun 16 '15 at 15:31
  • 1
    I'm uncomfortable putting this as an answer, because it's too opinion based, but I have had great success convincing people to use a "last known good" tag (LKG), which is a moving tag on the trunk identifying the last "blessed" version (CCB, testing, etc.). Developers are told releases will be done from this LKG tag, not the head of the trunk, and beyond that, they are free to use whatever approaches make sense to them at the time. I have found this pattern to spontaneously generate feature-branches when the time is right, without any up front effort or extra work on the developers' parts. – Cort Ammon Jun 16 '15 at 16:30
  • 1
    There's a reason people don't use branches with TFS. Trying to use a Git branching strategy in TFS is going to end very badly. – N Reed Jun 17 '15 at 00:54
  • 1
    This looks a lot like "I made some rules because I like making rules", and "The more complicated it is, the more respectable it looks". – phresnel Jun 17 '15 at 09:00
  • No coding standards at your place then? – MrBliz Jun 17 '15 at 09:06
  • I would say simple is good. Trunk for sprints, Release for Prod support. Others have noted that your branching strategy is very git specific. It's worth you and your team reading the [ALM Rangers branching guidance for TFS.](http://vsarbranchingguide.codeplex.com/) – James Reed Jun 17 '15 at 22:35
  • After working for 15+ years with CVS, Subversion, SourceSafe, Perforce and a few others, I now got the chance in a <10 developers Linux/Mac/Windows project to use git, [SourceTree](https://www.sourcetreeapp.com) and [git flow](http://nvie.com/posts/a-successful-git-branching-model/) others have already mentioned. In my personal opinion, this combination is the last word in version control (well, it will be as soon as there's a good GUI Linux client). In fact, it's so pain-free I don't even wanna say it out loud as not to jinx it ;-) – ssc Jun 22 '15 at 21:02

3 Answers3

32

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.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 3
    Well in this model, how are you going to stop unstable code getting on to production without branching? – MrBliz Jun 16 '15 at 12:34
  • 2
    @MrBliz: through switches. You can activate a feature for developers, but deactivate it for end users if it's not ready for RTM. – Arseni Mourzenko Jun 16 '15 at 12:36
  • 3
    Bearing in mind the experience of the developers that i'm working with, and the current lack of automated testing, i don't think that would be a good idea for our situation. – MrBliz Jun 16 '15 at 12:41
  • 4
    @MrBliz you stop unstable code getting on to production by isolating it in release branches (that's exactly their purpose) and by _testing_ it. Feature branches don't help in that; in fact these carry a higher risk of introducing instability by large, non-integrated, hard to control merges – gnat Jun 17 '15 at 00:34
  • Avoid branches at all costs. If you development team lacks skills they need to achieve this then that is your job as the senior developer to solve. Don't force your old ways on them. Train them to make the right decision and see what they create to solve the problems. – MrHinsh - Martin Hinshelwood Jun 17 '15 at 04:49
  • The OP sounds exactly like my experience three years ago, where I was the junior team member. The junior team members will look up to the project manager and believe whatever he says; if he's wrong about something, they won't figure it out for a couple years. Your answer should read, "be ready to be hated by **management**." Stuffed suits will never understand why he's reducing short-term productivity by trying to keep things organized. – Kevin Krumwiede Jun 17 '15 at 06:08
  • @gnat I explicitly stated that i would be having a release branch in the original post. – MrBliz Jun 17 '15 at 07:41
  • 1
    @MrBliz yeah I noticed that (and I think you got it about right, if only missed to explain the reasoning to support that). It's just that neither your comment nor this answer mention explicitly whether it's about release or feature branches (or both?), so I [commented to stress the difference](http://programmers.stackexchange.com/questions/286928/version-control-policy/286929?noredirect=1#comment592115_286929). FWIW being vague about this is probably the only thing that I dislike about this answer – gnat Jun 17 '15 at 07:51
  • +1 for "*be ready to be hated by your team members who will try to do whatever they can not to apply your concepts.*" You're trying to change *culture* here just as much as *process*. Developers are people too. – joshin4colours Jun 17 '15 at 17:37
16

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.
17 of 26
  • 4,818
  • 1
  • 21
  • 25
  • I think i'm leaning towards the long running release branch model. Thanks for your input. – MrBliz Jun 16 '15 at 15:01
  • 10
    *"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."* - How about code review? I think that's a good reason, even with only two devs. – BlueRaja - Danny Pflughoeft Jun 16 '15 at 18:00
  • 2
    Code review and branching aren't really related. Are you saying you don't want code checked in to a particular branch before it's reviewed? – 17 of 26 Jun 16 '15 at 18:11
  • 1
    @BlueRaja-DannyPflughoeft in my experience, code review didn't require isolation in branch. Folks simply pick commits to be reviewed, load them in Crucible and go ahead – gnat Jun 16 '15 at 19:10
  • 5
    @17of26, yes. Code review is typically used as a *prerequisite* to be on the mainline. Thus you have to show the code in some way before that: on your monitor, in an email, or -- in many setups -- on a branch. This works best with a repo management tool like GitHub or gerrit. – Paul Draper Jun 16 '15 at 19:12
  • 3
    TFS supports code reviews through shelvesets, which are temporary holding areas in source control. Code can live there until it's reviewed and then checked in. – 17 of 26 Jun 16 '15 at 19:45
  • 2
    I guess the point is, branches aren't really the right mechanism to use for doing code reviews. – 17 of 26 Jun 16 '15 at 19:46
  • @17of26: I'm speaking to you from the future, in 2016. Branches have become the de-facto standard for doing code reviews when using Git. – BlueRaja - Danny Pflughoeft Oct 14 '16 at 16:03
  • @BlueRaja-DannyPflughoeft but not when using TFS, which is what the original question is about. In TFS, if you want code reviewed before being checked into a branch you would use a shelveset. – 17 of 26 Oct 14 '16 at 16:27
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.

Mathiasdm
  • 131
  • 3
  • Effectively there would only be three active branches(release, release candidate, and trunk) at any one time, and most of the time just the release branch, and trunk. – MrBliz Jun 16 '15 at 12:57
  • Old branches will be deleted in TFS, or more accurately hidden. – MrBliz Jun 16 '15 at 13:12