locked
Como realizar Publish através de um Label ?? RRS feed

  • Pergunta

  • Olaa,

     

                        Sou iniciante no Team Foundation Server e possuo as seguintes dúvidas baseadas no cenário explicitado abaixo:

    Cenário:

     

                Possuo um Branch denominado Repositorio, no qual uso o Label para homologar diferentes versões ao longo do meu processo de desenvolvimento. Após a criação de dois labels denominados versão 1.0 e versão 2.0, necessito realizar o Publish para o servidor de teste da versão 2.0, como realizar o publish desse Label ?? qual a forma mais adequada de realizar tal ação ??

     

    Desde Já, Agradeço.

    sexta-feira, 20 de maio de 2011 20:11

Respostas

  • Fala Rodrigo,

    É sempre um prazer poder ajudar, não precisa agradecer. Particularmente eu faço isso porque gosto e espero realmente conseguir ajudar.

    Primeiro, desculpa se ficou alguma impressão errada do que eu falei, porque eu fiz a descrição do modelo. O que eu queria era apenas colocar alguns exemplos.

    Eu confesso que fiquei um pouco perdido nas nossas trocas de mensagens e sobre o que você disse sobre afirmação acima, aí na dúvida vou falar dos dois que eu estou achando, me corrija se estiver errado.

    Mas sobre o seu caso do repositório, eu usaria os branches 3 (um de dev, um Main e um Release) e nas suas releases com o label para rotular as grandes versões. O que você terminar ao final da sua sprint você pode controlar através do changeset e um comentário que já é gerado automaticamente quando você fizer o check-in no branch release. Esse check-in você deve fazer sempre de todos os arquivos juntos ou um merge entre os branches, para ter todos os documentos em um único check-in.

    Sobre a afirmação da sprint e release, você não deve considerar a versão apenas quando terminar todo o ciclo, até porque no modelo scrum o projeto só vai acabar quando acabar nossos Product Backlog Items. As versões maiores que seriam V1 e V2 etc, seriam baseado no seu plano de release que é o conjunto de sprints. Nesse modelo cada parte do sistema que você terminasse na sprint você poderia considerar com versões menores V0.1, V1.1, V1.2 etc.

    Esse é até o modelo que tá no post do Bill Heys sobre branches para times que utilizam Scrum (http://blogs.msdn.com/b/billheys/archive/2011/01/18/branching-for-scrum.aspx ). Veja que nesse modelo as sprints geram as versões menores V0.n e na continuidade que fecharemos o modelo do Release.

    Novamente, desculpa por qualquer mal entendido que tenha ficado.

    Abs


    Claudio Leite Visual Studio ALM Ranger | PSD Trainner by Scrum.org Twitter: @claudiobernardo Blog: http://www.claudioleite.com
    • Marcado como Resposta _dev quarta-feira, 25 de maio de 2011 13:31
    quarta-feira, 25 de maio de 2011 01:52

Todas as Respostas

  • Rodrigo,

    Bom, na teoria o seu Branch Repositório deveria ter sempre a última versão que deverá ser publicada, por tanto o uso do Label seria apenas para saber o momento e os arquivos publicados. Se no seu label repositório você tem a versão 1.0 e a versão 2.0, acredito que as duas já estão homologadas e finalizadas, então o ideal seria você publicar apenas a versão 2.0, assim seu sistema estará sempre com a versão mais nova publicada.

    Se você precisa publicar diferentes versões do seu sistema porque você possui clientes que o utilizam em ambientes separados, o ideal seria você ter cada uma dessas versões em um Branch, pois vai facilitar muito a sua gestão de configuração e mudança. Sempre que alguma versão não estiver mais sendo utilizada por algum cliente, significando que você não precisa mais manter aquela versão especifica, você deveria apagar esse Branch, afinal já que ninguém mais utiliza ela e você não precisa dar suporte, porque manter esse código ?

    Mas se mesmo assim, você precisar utilizar um label especifico para fazer a publicação, conheço duas maneiras que você pode fazer.

    1 - Utilizando o próprio Visual Studio 2010, você pode baixar para o seu workspace a versão daquele label que você quer realizar o publish, compilar e utilizar a ferramenta de Publish no menu de contexto do projeto (botão direito no nome do projeto).

    2 - Utilizar um sistema um pouco mais elaborado com automação de build e webdeploy. Você teria que instalar nos seus servidores de IIS a ferramenta WebDeploy. Depois de instalar o WebDeploy, você cria uma build definition e altera alguns parametros da build para usar o WebDeploy.

    Abs


    Claudio Leite Visual Studio ALM Ranger | PSD Trainner by Scrum.org Twitter: @claudiobernardo Blog: http://www.claudioleite.com
    sábado, 21 de maio de 2011 00:05
  • Prezado Claudio Leite,

     

                                       Novamente obrigado pela atenção, referente ao problema citado, eu preciso manterarmazenado no TFS as diferentes versões geradas ao longo do processo de desenvolvimento, mas a melhor forma de armazenar essas versões é algo que AINDA NÃO está CLARO, portanto segue as dúvidas abaixo:

     

    a) Usar 1(UM) Branch denominado Repositório e Homologar (ARMAZENAR) essas versões com Labels é uma má prática ? é uma pratica não aconselhada ?  

     

    b) Levando -se em consideração que a utilização do Label sejá algo não aconselhado a ser feito e que preciso ARMAZENAR essas versões, qual a melhor forma de  realizar tal tarefa ? Sendo que consideramos uma prática COMPLEXA criar UM BRANCH para cada versão gerada pelas iterações

     

    OBS: Deve-se levar em consideração que trabalhamos com o Scrum e que temos que  Homologar(ARMAZENAR)versões a cada iteração. 

     

    Desde Já, Agradeço.

    segunda-feira, 23 de maio de 2011 13:41
  • Rodrigo,

    Trabalhar com o labels e branches não existe uma resposta se é boa prática ou não. O que temos que descobrir é o que melhor se adequa a cada caso dada as necessidades do projeto, cliente, etc.

    Talvez tenha me expressado mal, mas a utilização de label NÂO É considerada uma má pratica. Ela deve ser utilizada sim, só que conforme mencionei anteriormente, depende de cada caso.

    Você no seu caso poderia usar os dois, o Branch e o Label. Pode usar o label para "marcar" os arquivos que compõe aquelas versão. Assim você tem o seu histórico e rastreabilidade. Mas para jogar para a produção o ideal seria sempre jogar a última versão, então nesse caso, não interessa se seria a versão 1 ou versão 2 e sim a última versão publicada. Se você não conseguiu publicar nenhuma delas, então não existe a versão 1 ainda, por isso que não faz a diferença, entendeu ?

    Acho que o problema pode ser um pouco mais conceitual do que técnico e de como armazenar. Estou considerando que você trabalha com Scrum e que tem que homologar as versões.

    Trabalhando com o Scrum, nós realizamos nosso planejamento divindo mais ou menos o que faremos em sprints, que estarão dividas em releases. Então uma release é composta por 'N' sprints.

    Temos por definição que ao final de uma sprint realizada com sucesso, teremos algum pedaço do software que tenha valor para o cliente e que pode ser instalado em produção.

    Outro ponto importante é que devemos ter a não definição de pronto, que vai nos ajudar, como um time do projeto a saber o que consideraremos como pronto, quais os critérios que colocamos para considerar uma funcionalidade como pronta.

    Beleza, tendo esses principios do Scrum, ao final da sprint teremos sempre um produto pronto para entregar, então não teremos o conceito de versão a cada sprint fechada com sucesso e sim alguma entrega.

    Nesse modelo não existe uma real necessidade de guardar a versão correta do sistema que foi liberada em cada sprint. Aí que surge a minha dúvida, porque você precisa de ao final de cada sprint ter esse rótulo da versão? Qual regra do seu negócio que pede isso? Talvez se você explicar mais a sua realidade de negócio podemos encontrar uma solução mais adequada.

    Abs


    Claudio Leite Visual Studio ALM Ranger | PSD Trainner by Scrum.org Twitter: @claudiobernardo Blog: http://www.claudioleite.com
    terça-feira, 24 de maio de 2011 01:54
  • Prezado Cláudio Leite,

     

                                 Não tenho como agradecer a sua atenção e dedicação nas respostas, acredito que eu tenha confundido conceitos.Como trabalho com Scrum e convivo diretamente com esse conceito de iterações, levei em consideração que a entrega de um Sprint correspondesse a uma versão pronta do sistema, devido a tal fato estava me referindo a homologação de versões e não de iterações. Sendo que so devo levar em consideração o conceito de versão quando todo ciclo de desenvolvimento estiver encerrado e com um produto usavel pelo cliente. Qual a sua opinião a respeito do que foi citado acima ? Você acha que a afirmação acima foi colocada da maneira correta ?

     

    Desde Já, Agradeço.

    Um grande abraço.

    terça-feira, 24 de maio de 2011 14:14
  • Fala Rodrigo,

    É sempre um prazer poder ajudar, não precisa agradecer. Particularmente eu faço isso porque gosto e espero realmente conseguir ajudar.

    Primeiro, desculpa se ficou alguma impressão errada do que eu falei, porque eu fiz a descrição do modelo. O que eu queria era apenas colocar alguns exemplos.

    Eu confesso que fiquei um pouco perdido nas nossas trocas de mensagens e sobre o que você disse sobre afirmação acima, aí na dúvida vou falar dos dois que eu estou achando, me corrija se estiver errado.

    Mas sobre o seu caso do repositório, eu usaria os branches 3 (um de dev, um Main e um Release) e nas suas releases com o label para rotular as grandes versões. O que você terminar ao final da sua sprint você pode controlar através do changeset e um comentário que já é gerado automaticamente quando você fizer o check-in no branch release. Esse check-in você deve fazer sempre de todos os arquivos juntos ou um merge entre os branches, para ter todos os documentos em um único check-in.

    Sobre a afirmação da sprint e release, você não deve considerar a versão apenas quando terminar todo o ciclo, até porque no modelo scrum o projeto só vai acabar quando acabar nossos Product Backlog Items. As versões maiores que seriam V1 e V2 etc, seriam baseado no seu plano de release que é o conjunto de sprints. Nesse modelo cada parte do sistema que você terminasse na sprint você poderia considerar com versões menores V0.1, V1.1, V1.2 etc.

    Esse é até o modelo que tá no post do Bill Heys sobre branches para times que utilizam Scrum (http://blogs.msdn.com/b/billheys/archive/2011/01/18/branching-for-scrum.aspx ). Veja que nesse modelo as sprints geram as versões menores V0.n e na continuidade que fecharemos o modelo do Release.

    Novamente, desculpa por qualquer mal entendido que tenha ficado.

    Abs


    Claudio Leite Visual Studio ALM Ranger | PSD Trainner by Scrum.org Twitter: @claudiobernardo Blog: http://www.claudioleite.com
    • Marcado como Resposta _dev quarta-feira, 25 de maio de 2011 13:31
    quarta-feira, 25 de maio de 2011 01:52
  • Prezado Claudio Leite,

     

     

                                       Você tem nos ajudado bastante e não há como não agradecer, pra quem está começando a sua paciência e dedicação é de extrema importância, nem sempre as pessoas em foruns são pacientes e prestativas. Todas as dúvidas foram sanadas, os conceitos ficaram mais claros.

     

    Desde Já, Agradeço.

     

    Um grande abraço e uma boa semana.

     

    Eu e meu colega de trabalho Tiago postamos uma tweet e gostariamos de segui-lo.


    quarta-feira, 25 de maio de 2011 13:30