Source Control: Roles and Responsibilities - Best Practices

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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