3

I am in an enterprise that creates many large to small scale applications. Way back when I started using Visual Studio Online/VSTS/now Azure devops I broke all of these apps out into different projects. However, now it seems there is good support for managing multiple apps in one project, and this seems easier from a management standpoint.

From the research I did it seems i can do each service individually:

  1. Repos: Select Import Repository from the consolidated project and enter in the URL of the app i want to import BEWARE

Also, the system automatically resets the State and Reason fields to the default initial values for the work item type that you move.

and I skimmed over the docs and missed that snippet. oops

  1. Boards: Go to query (optionally select query across project) and move all items to the consolidated project (creating the appropriate teams, areas and past sprints to keep history)
  2. Builds: Export json from source projects and import to consolidated project
  3. Releases: Same as Builds

(we do not use test plans or artifacts at the moment)

Doing it this way I probably will loose build and release history, which is probably not a big deal once enough time passes, but I did not find any other good way.

My two questions are:

  1. Are there better guidelines to move entire projects to one project?
  2. Will I permanently or temporary loose anything else besides the build and release history that I am not realizing?
jmzagorski
  • 1,135
  • 18
  • 42
  • 1
    Agree with Bevan , there should be no better way to do this now.Merging projects into a project is currently not supported in azure devops. – Hugh Lin Aug 26 '19 at 10:45

1 Answers1

1

I went through the same thing and had to do what you described. At the time there was no support for moving services/functions between Projects or Orgs at all, let alone consolidating into a single Project. Unless something's changed, short of automating via your own API scripting it's all manual.

The other watch outs were mainly around access and security:

  • External API integrations such as Web Apps, Function Apps, JIRA, Service Now
  • External inbound app authorisations
  • External outbound app authorisations such as Azure Service Principals
  • Variable Group authorisations to YAML Build Pipelines
  • Library reference updates including KeyVault
  • etc

This refactoring ended up being much more work than the platform consolidation itself.

Bevan
  • 1,305
  • 1
  • 11
  • 17
  • Thank you. I suspected as much. Did you loose build/release history or can that be copied too? – jmzagorski Aug 26 '19 at 13:31
  • Yeah lost the history. Unfortunately it's bound to the original build/release and doesn't persist like repo history. – Bevan Aug 26 '19 at 13:37
  • So do you have multiple unrelated applications in one project? I was struggling with how best to setup the teams. I started creating `ui-team`, `cli-team` and `api-team` since developers support many different apps, but then it is hard to determine which backlog item is for which app in those teams, and then integrating with Microsoft Teams is challenging since Kanban boards are by teams and our Microsoft Team pages are by application. If i create a team per application, I feel that may be a lot of teams. – jmzagorski Aug 26 '19 at 14:12
  • Kind of unrelated applications. I have one Project per Team and each team has all of their projects/applications in the one Project. Work Items is a bit clunky but works. You can create custom fields for each Item (Bug, Epic, etc). For example, you can add an "Application" field which you would populate with ui-team, cli-team or api-team when you create the ticket. Then you add the column onto your Board and filter, or create Custom queries which pull info from the new "Application" field. – Bevan Aug 27 '19 at 01:52
  • Make sure you test it in your own personal Org first because changes to Work Items, such as custom fields, are global so apply to every Project in your Org. – Bevan Aug 27 '19 at 01:54
  • Thanks. I went with the Team per application in my one project instead of the original `ui`, `cli`, `api` etc. It is a little more work to put people on teams, but the reporting and backlogs are worth it – jmzagorski Aug 27 '19 at 21:30