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.
It largely depends on what fields you would want, as 17 of 26 indicated: TFS is highly customisable. The reason I would want to do this as opposed to use something like JIRA is that you get a single view of what your developers are working on, as opposed to having to aggregate two systems.
TFS also has resource capacity planning, and if you're not showing production defects in your planning (and they take up a significant fraction of your time), then you're not really planning your capacity. I would in fact say that this is an ideal solution for teams where the developers make use of TFS and support Production (e.g. DevOps).
It doesn't mean you can't use other tools for the main Production Support/ITIL work, you'd just need to make sure they integrate, either manually or preferably automatically. Most such tools allow you to put in custom hooks, and TFS certainly does.
Anyway, to the main question. I use the CMMI TFS templates (which actually work fine with Agile BTW), and I just added a single field to one of the drop downs.
Here are the steps:
Install TFS Power Tools
Open the Work Item Template from the server
Edit the Discipline field
The discipline field is the "kind" of work related to the defect. The standard values are:
- Analysis
- User Experience
- User Education
- Development
- Test
What we're just going to do is add "Production" to that list. First, edit the Discipline field:
Then, click the Rules tab and edit the ALLOWEDVALUES rule:
Then, Click "New", and add in "Production" as one of the values.
Click "OK" repeatedly until you're back at the field list.
Save the Work Item Template
OK, now you're done. You can create new Bugs and indicate their type as Production. I'd also create a few Work Item Queries looking at Production defects, and add them to your pinned items. Finally, look at the existing Bug queries, and maybe change their ordering so that "Production" bugs come up first (if that's possible).
Best Answer
As Max said, you could create a task specifically devoted for the merging Dev into main process and then track which changesets have been associated with that task.
Also, you can read on every build journal the list of the changesets used for the build.