ALM, DevOps

Migrando Work Items entre Team Projects

Esta semana surgiu a necessidade de migrarmos os Work Items de um Team Project para outro dentro do Team Foundation Server, hoje no Visual Studio Team Services temos a funcionalidade incorporada, porém no Team Foundation Server ainda não.

Com isso durante algumas pesquisas e testes localizei o VSTS Work Item Migrator, um código desenvolvido e disponibilizado no GitHub.

A utilização dele é muito simples, primeiro acessamos o projeto de origem e criamos uma Query que liste todos os Work Items que serão migrados, conforme exemplo abaixo:

image

Agora temos que acessar o arquivo .JSON no diretório WIMigration e iniciar as configurações de migração:

Configurações do projeto de origem
"source-connection": {
      // fully qualified url for the source account
      "account": "http://vsalm:8080/tfs/DefaultCollection",
      // the name of the project to migrate from
      "project": "ProjetoOrigem",
      // the personal access token to use when accessing the account.
      // this requires work item read permissions to all work items
      // that are expected to be migrated.
      // note: personal access tokens require https
      "access-token": "g74k4ez5lwvdhhdosaixhnhrcupvqkritz5opnfmgv7d3kl7d2lq",
    // when connecting to TFS, you can use NTLM instead of an access token.
    "use-integrated-auth": "true"
Configurações do projeto de destino
"source-connection": {
      "target-connection": {
    // fully qualified url for the target account
    "account": "http://vsalm:8080/tfs/DefaultCollection",
    // the name of the project to migrate to
    "project": "ProjetoDestino",
    // the personal access token to use when accessing the account.
    // the user is required to be a project collection administrator.
    // note: personal access tokens require https
    "access-token": "g74k4ez5lwvdhhdosaixhnhrcupvqkritz5opnfmgv7d3kl7d2lq",
    // when connecting to TFS, you can use NTLM instead of an access token.
    "use-integrated-auth": "true"
Configuração da Query base

"query": "Shared Queries/WorkItems",

Configuração de Tags
// the tag to stamp on the work items on the source project
 // once the migration is complete.
 "source-post-move-tag": "Migrado",
 // the tag to stamp on the work items on the target project
 // once the migration is complete.
 "target-post-move-tag": "Migrado do ProjetoOrigem",
Configuração de Iteration e Area Path
// the tag to stamp on the work items on the source project
"default-area-path": "ProjetoDestino",
  // when the iteration path doesn't exist on the target project, the migrator will use this iteration path
  // instead of defaulting to the root.
  // note: if skip-work-items-with-missing-iteration-path is true, this setting is ignored.
  "default-iteration-path": "ProjetoDestino",
  // if the account has any identities with emojis, it's possible migration
  // will fail if the identity with an emoji has not been added to the account.
  // This setting will remove the display portion of the identity to ensure
  // migration will succeed.

Após a configuração dos parâmetros de migração via prompt de comando temos que validar o processo antes da migração oficial:

dotnet run -v configuration.json

image

Com a validação finalizada com sucesso partimos para a migração oficial executando o comando:

dotnet run -m configuration.json

SNAGHTML6faec2

Pronto com isso os Work Items foram replicados no projeto de destino:

image

Até a próxima.

Não quer perder mas nenhuma informação sobre ALM e DevOps, então não esqueça de me acompanhar nas redes sociais

Deixe uma resposta