2

I've recently taken up a task of simplifying and automating processes in our development pipeline, and I'm looking for suggestions/advice of others on what was done for similar problems.

We currently use TFS 2019/Azure Devops and a branching strategy of:

Master
└ Major Version 1 QA
└ Major Version 1 Release
└ Major Version 2 QA
└ Major Version 2 Release

We use work items in TFS and link them to change sets to the branches above. Typically, all work is done in Master and selectively merged to QA in either or both versions one by one.

Once tested/verified the changes are typically merged en-masse to Release where they undergo another round of testing before making their way to the public.

These merges aren't always en-masse, sometimes they are done one by one, sometimes a change gets merged from Main>QA>Release in one shot (three check-ins for one thing...).

Additionally, we have a separate bug tracking system that is used to collect bug reports from CSRs and that system provides status to external members (people without TFS access). This setup requires a human to duplicate data from TFS to the external system (and vice versa) which is a major inefficiency I am trying to solve for.

Currently the TFS work item holds all the notes and provides a relationship to specific code changes. I would like to move everything into TFS and ditch the external system which presents the following challenges and questions:

  1. How can I provide a searchable, read-only view of work item data to external non-devs? Adittionally, does TFS have a simple "report a bug" kind of role? I feel like something like this should already exist, but it seems I would need to create or identify something that integrates with TFS.
  2. When merging changes en-masse, individual work item association to a code change is lost. It appears this is a long standing complaint about TFS, and I think I would need to script the merges individually to achieve automation. Are there other ways?
  3. Considering the branch strategy above, any change to a file requires at least 3 check-ins to make it into the world. Is that a good strategy? The idea behind it is that work can continuously be added while the Release branches are frozen.

Additional Info:

We're a small team of 5 Devs and 5 QA with a 20:1 larger external infrastructure built around our products which is why I am looking to automate.

Thank you for your advice/suggestions!

Dev1230
  • 23
  • 2

1 Answers1

0

1.It's not a recommend usage in TFS.

TFS is not intended to be a public bug tracker. On-prem TFS uses Windows AD for authentication. Azure DevOps Service(cloud) uses Microsoft accounts or Organizational accounts (backed by Azure AD).

Beyond that, there is no concept of restricting certain work items to certain users -- any user who has access to edit work items in a given area can edit all work items in that area.

Source Link: Can TFS be used as a public bug reporting tool?

If you insist to do this, a better way is doing this with the help of some 3rd-party tool. You could take a look the answer from Ewald Hofman our PG in this question: Handling bugs raised by customers in TFS

2.You are correct. In TFS, when you merge branches, the resulting Changeset is linked to all Changesets merged. TFS =does not provide the option to select associated work items in Merge dialog, we should manually add the work items in Pending Changes window before click Check in button to perform check-in on merge branch.

You may need to customized script to achieve it. Besides, you could also use or refer some 3rd-party tool/extension, such as this one-- TFS merge work items plugin

3.We could not judge it's a good or bad strategy. It's good if totally match what you are looking for. If you worried about the check in times and numbers of changesets. First, when you merge changes to Release. Usually there are multiple changesets. You do not need to do this if there is only little changes to a file. In other words, you don't have to check in frequently. You could also choose pending work with a shelveset, not need to check in each update.

Besides, for more choices, you could kindly refer our official link here: Learn about branching strategies for Team Foundation Version Control (TFVC) and how to select an effective strategy

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62