I'm looking for "Best Practices" concerning roles and responsibilities, specifically who is responsible for merges from development branches to trunk (or main). Basically I'm looking for ammunition to help my cause.

Let me describe what I'm facing. I am the lead developer (owner) of a particular application. Our company recently moved from VSS (where I was the administrator of the VSS database in which my application was stored) to TFS (where I only have permissions on development branches created by our "operations" team). In previous jobs, I was a TFS Admin, so I know my way around TFS and MSBuild.

I don't have an issue with the branching and merging strategy being used (main branch, with bug/project development branches created as needed, merged back to main then promoted to a release branch). The issues I have are:

  1. I cannot create my own branches. I must create a TFS task to have an "operations" team member create the branch for me.

  2. I cannot merge from Main to my development branch. I must create a TFS task to have an "operations" team member perform the merge, and then hope he doesn't "step on" any of my teams changes since the "ops guy" may or may not be a developer and certainly has little to no knowledge of the code he is merging.

  3. I cannot merge from development to Main. Again I must create a TFS task to have the "ops guy" perform the merge, hoping that he does it correctly. Then I have to create another TFS task to merge back to my branch so that I can resolve any issues which have occured by having a non-developer merge to Main.

  4. I cannot create or edit MSBuild scripts. Again I have to work with the "ops" team which is new to MSBuild so only the most basic build tasks can be performed. (Forget about anything complex, or heaven-forbid a custom task).

  5. I cannot execute an MSBuild script. Again only the "ops" team can do this.

  6. To top all of this off, typically it is an "off-shore" resource which performs the requested tasks, so even if I create the task to (branch/merge/build) in the early morning, it probably won't be completed until that evening.

Now I have no issue with the "operations" team maintaining the release branches. As all they are doing is (basically) taking the latest version from Main and promoting it to the release branch; so as long as "Main" is stable and ready, the release branch will be good.

My opinion is that technical leads (such as I) should be responsible for maintaining the trunk ("Main") and any merging to/from the development branches. The team lead should also have the ability to generate MS Build scripts to build and deploy to the Integration test environment.

Can anyone direct me to a Best Practices document that'll help me prove my case? All my searching has turned up only Best Practices concerning the techniques of branching and merging, and no mention of WHO should be performing said branching/merging.

  • WHO should be performing said branching/merging. is an internal organizational decision. Not really something we could help you with...
    – yannis
    Jan 31, 2012 at 19:33
  • 2
    Care to tell us the putative reasons given for such a byzantine procedure? My guess is "CMM Level N compliance" or "Sarbanes Oxley". Jan 31, 2012 at 20:44
  • SOX, but only in part. When we first went to TFS, developers had access to Main and Dev. But then "some" developers (none on my team) decided to just do development work on Main rather than in a Dev branch, so now all teams are being punished. Jan 31, 2012 at 22:50

3 Answers 3


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.

  • 3
    +1, I was typing something similar: document the lost time and effort: let decision makers make an informed choice: is the risk of whatever they are trying to avoid with the current restrictive policy worth the cost?
    – Jamie F
    Jan 31, 2012 at 20:19
  • I plan on having such a meeting, but it would help if I could show this policy goes against industry "best practices". Jan 31, 2012 at 22:51
  • Gotcha. Not sure if anything specific is in there, but the bits on source control in The Pragmatic Programmer might have some gems in them. From what it sounds like it was a gross overreaction to some bad developers rather than a thought out policy decision or some politics. I'd settle for a deal where Ops owns merges into Main. I'd also push to make ops responsible for ensuring the merge don't break anything, which will probably end up with them getting out of it . . . Jan 31, 2012 at 23:04
  • I second Jamie, all the time spent merging or waiting for a merge to happen should be recorded so that you have evidence. There is no "best practice" that fits all companies. I have worked in large company where this task was done by a dedicated configuration management team. I my current company there is a dedicated release management team that doesn't do the physical job of merging to main but they are the logical owner and do audit it. But IMHO ops is not usually the one that touches source code.
    – softveda
    Feb 1, 2012 at 5:42

Practices I've seen are:

  1. Anybody can create work branches to their heart's content. A developer must be able to create a feature branch in the second they find there is a point in storing their current work in progress. Because they want/should back it up at the end of the day, want to share it with another team member, need to be shielded from changes in main or whatever.

  2. Anybody can do absolutely anything to development branches. Developer must be able to merge from main the minute another developer tells them something they need has been integrated in main.

  3. For merge to main (integration), there are three options:

    • Developers do this themselves. They just discuss the risks with the lead developer and test the features appropriately. That implies anybody has the permissions; if somebody breaks the rules, they just get scolded and the wrong change is reverted.
    • Another developer does it after reviewing the changes. It still requires everybody has permissions to do it; rules are still enforced by the lead developer.
    • There is designated integrator who reviews and merges into main. But the integrator is part of the team and needs to understand the code. On smaller team it would be the same person as architect, on larger they would be separate, but would need to cooperate closely.
  4. Whoever prepares a feature should adapt the build script. But I am not sure how it works with TFS; in the systems I used the build script was always just a versioned file, so developers edited it just like any other and it was integrated along with everything else.

  5. If there is a designated integrator, they usually take care of defining (which script to run) and starting the builds. Otherwise either the team lead does it, designated team member does it or anybody has permissions and the team lead delegates setting up and starting particular builds on a case-by-case basis.

  6. In no case should above operations require operator outside the team. Operator is only needed for setting up the permissions, creating replicas and such.

  • I'd be all for a "designated integrator", just as long as it's actually a developer on the team. That's the route I'm hoping for anyway; it's a small team (4 people including myself). Hopefully I can get access to create/execute the MS Build scripts too, it'll be silly for me to create nAnt scripts for development deployments and then for the "ops" team to build essentially the same script for MSBuild. But, that's what I'll do if needs be. Feb 1, 2012 at 23:09

Never mind "best practices" (bear with me) this is a management problem - fundamentally you are not able to do you job properly because of the constraints placed upon you.

It doesn't actually matter what "best practice" is - this is a simple, demonstrable, issue that will affect the productivity of you and your team and you need to take it up with your line management on that basis.

I can see that brandishing a best practice document might (but only might) be an aid in attempting to persuade them but far better is the notion that you will have to have dev team members sitting on their hands whilst waiting for someone in a different timezone to get their act together unless the processes are improved/rationalised.

And don't be too confrontational - as much as anything you want to know why the restrictions are in place, what the justification is...

  • 1
    Yes, trying very hard not to be confrontational... coming from a guy who's wife bought him an "I'd agree with you, but then we'd both be wrong" T-Shirt. :) Feb 1, 2012 at 23:06
  • Its an absolute killer when you're right (-: And in this case its hard to argue that you're not... but you need your line management on-side if anythings going to change
    – Murph
    Feb 2, 2012 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.