Microsoft’s TFS has been going a long way from a version control system (VCS) to an integrated system for its Application Life-cycle Management (ALM) solution, and to a platform providing DevOps pipelines for various systems and tools. Just like any other modern tools trying to solve chronicle complex issues, the solution itself becomes more complicate and takes time to master. Below is a case study for using TFS to build release pipelines to resolve multiple issues at once.
Symptoms
Human errors when getting the right version of code from TFS
Extra effort require and sometimes missed to merge code after Prod deployment
Untrusted code base due to inconsistent merging
Assesment
The teams have been using TFS for a while since TFS 2012.
Not too many team members are familiar with all aspect of a software release management including branching & merging, automation, integration, and collaboration in addition to TFS tools.
Analysis
(3rd party) Ticket-based development & deployment
Cherry-pick merging strategy
Infrastructure teams handle the manual deployment, not interested in any changes on their end
Diagnosis
Label changeset items with 3rd-party tickets to track all changes and scopes
Grab items based on labels to hand over to deployment teams to avoid human errors from reading file lists and do it manually
Use service hooks (Code Checked In) to apply labels to save developers time and hassle to label them individually (sometimes more than 100 items per tickets)
Use pre-deploy approval emails as notification to deployment teams
Use post-deploy approval notification as confirmation of the deployment from deployment teams
Developers initiate/continue Prod environment deployment with the same build artifacts when passed QA and business users tests. Build once, deploy multiple environments
Use service hooks (Release Deployment Completed) to merge code from QA to Prod after successful deployment to save effort
Apply an additional day-based label across all applications for easy auditing of what goes to Prod on any particular days
Solution
Map 3rd party ticketing system to TFS with a custom field on one-to-one basis
Associate single work item with each changeset/check in
Create custom Service Hooks to label items based on the 3rd party ticket numbers
Create build definitions per developer and queue them by labels
Create release definitions per developer and dropping the packages to Infrastructure/Operation teams for manual deployment
Use pre-deploy and post-deploy approval process for communication
Create custom service hooks after successful production deployments
To merge code from QA to Prod based on label automatically
To label all production code with date for audit purpose
If you are interested to know the broader view of how TFS manage users and groups, you can refer to this post. To recap, here are some pros and cons.
PROs:
Take the burden of “approving” user access – Unless it’s for a pretty small company, TFS administrators are not actually approving anybody’s access anyway. They are just doing the actual work. Even worse is that if the access request starts at TFS team, there will be more emails/IMs going back and forward between TFS team and Dev managers before an user’s access is granted. There is yes and no desision and how, where, and what to the access level. The decision makers should be in Dev team’s hand. We just need to make sure all parties fully understand the scope and meaning of those access.
Should users left the company, we can just take care the accounts from AD (by Network/Security teams) and not worry too much about maintaining the integrity of user lists especially now TFS has multiple components like Code, Work, Build, and Test to manage. Needless to say those integration outside of TFS like SharePoint and SSRS.
CONs:
It is not Agile any more. Now the whole “processes” are more corporate/audit oriented. Team leaders can not easily to utilize boards as planning and communication tools before. I think it is a trade-off, depends on where your organization at in the lifecycle of organizations.
More managing overhead. This is kind of contradict to the point above. We tried to eliminate the headache from TFS administrators by adding more layers and groups to the equation. Eventually the AD groups will grow into something that even those Dev teams not sure which group is the right group to put people and what the impact is for different combination of the groups.
Just in case you are still interested in using AD groups alone to manage TFS users. Here are some AD groups you will need.
Heal My SCM 
