locked
Organizando Team project collection e Team project RRS feed

  • Discussão Geral

  • Olá pessoal!

    Estamos utilizando o TFS 2012 mas com algumas dificuldades na organização do "Team project collection" e do "Team project"

    O cenário é o seguinte:

    Temos uma solution que é a biblioteca base (core) para todos os times/sistemas. 
    Esta solution todas as equipes precisam ter acesso para fazer a referência em seus projetos.

    Exemplo: empresa.core

    Temos vários times/sistemas diferentes que utilizam o TFS para seus projetos com controle de backlog, work items, sprints, áreas, etc.
    A gestão do backlog é feita por time/sistema.
    Um time NÃO pode acessar os dados/código do outro time, nem o backlog ou work items. Apenas a solution "core" é compartilhada.

    Exemplo:

    empresa.sistema1 (backlog1 e suas sprints)
    empresa.sistema2 (backlog2 e suas sprints)
    empresa.sistema3 (backlog3 e suas sprints)

    Opções que tentamos:

    a) Criar 1 Team project collection e apenas 1 Team project.
    Desta forma, conseguimos compartilhar o código e restringir os projetos necessários.
    Neste caso criamos "áreas" para cada time organizar seu backlog. Porém, todos os times conseguem acessar as informações de todos e ainda temos que criar queries específicas para os work items.

    b) Criar 1 Team project collection e um Team project para cada time/sistema.
    Desta forma, conseguimos restringir os projetos necessários, porém NÃO conseguimos compartilhar as solutions que precisam ser compartilhadas.
    Neste caso criamos cada team project tem suas "áreas" para organizar seu backlog.

    Alguém tem alguma sugestão para organizar melhor este cenário?

    Obrigado!

    Alvaro


    • Editado Alvaro Brognoli segunda-feira, 21 de janeiro de 2013 13:45 Erro digitação!
    quarta-feira, 16 de janeiro de 2013 19:28

Todas as Respostas

  • Oi Alvaro,

    na empresa que trabalho atualmente nós temos um cenário similar.

    No nosso caso, o que seria essa Solution compartilhada, na verdade é uma Framework interna.

    Neste caso a minha recomendação seria adotar a opção B, mas também criando um Team Project para as Solutions que seriam compartilhadas. Dessa forma, seria possível acompanhar a evolução dessa Solution de maneira independente incluindo o Source Control e Work Item Tracking.

    Essa é o formato que estamos utilizando atualmente.

    Abraços!


    Alan Correa Morais [MCTS - Visual Studio 2010 Team Foundation Server, Administration]

    sexta-feira, 18 de janeiro de 2013 19:47
  • Olá Alan, obrigado pelo esclarecimento.

    Mas como vocês fazem para compartilhar essas Solutions da framework para um Team Project diferente, dentro da mesma Collection?

    Compartilham apenas as DLLs e PDBs? 

    Um abraço!

    Alvaro

    segunda-feira, 21 de janeiro de 2013 13:49
  • Olá, é isso mesmo!

    As referências serão todas realizadas por DLL. 

    Mas no caso de necessidade de se fazer debug, são necessários os arquivos PDBs.

    Obrigado pela ajuda!

    terça-feira, 22 de janeiro de 2013 15:45
  • Alvaro,

    Espero que ainda possa ajudar.

    Trabalho em consultoria, fazendo implantação do TFS. Hoje todos os clientes a primeira recomendação que tenho feito é trabalhar apenas com um Team Project.

    Nesse caso eu te indicaria o primeiro modelo. Apenas para entender o cenário, vc criou as áreas "na mão" ou criou os times (Teams) no TFS ?? Isso faz uma grande diferença.

    Se você criou as áreas apenas você vai ter uma gestão um pouco mais complicada. Se você criou os times, vc consegue dar as permissões especificas para os times o que vai facilitar muito a sua vida. Quando um dev precisar ver mais de uma aplicação, simplesmente coloque ele no time especifico.

     

    Para a opção 2, sugiro você dar uma olhada no Branching Guide dos ALM Rangers ( http://vsarbranchingguide.codeplex.com/ )na parte de Shared Resources. Lá tem exemplos de como vc trabalhar o seu segundo cenário e ter esses recursos compartilhados.

    Para os PDBs o ideal é vc ter um symbol server no seu ambiente. Na prática é só ter uma pasta compartilhadas onde todos os seus devs tenham acesso. O legal disso é que na Build Definition vc pode indicar para o TeamBuild, jogar os últimos pdb´s para essa pasta.

    Assim se você precisar de algum pdb basta ir na pasta e pegar a versão desejada.


    Claudio Leite Visual Studio ALM Ranger | PSD Trainner by Scrum.org Twitter: @claudiobernardo Blog: http://www.claudioleite.com

    terça-feira, 19 de fevereiro de 2013 21:11
  • Olá Pessoal!

    Obrigado pela contribuição Cláudio!

    Nós estamos trabalhando com um Team Project para cada sistema e um separado para o framework.

    Esta opção se adaptou muito bem ao nosso cenário, pois os times são bem definidos.

    Referente a publicação dos PDBs, realmente o Team Build é muito bom!

    Abraço a todos!

    Alvaro Brognoli

    terça-feira, 26 de fevereiro de 2013 19:28