[quote=fidelis felipe]Pois é, ando pesquisando sobre melhores praticas para se trabalhar com branche, tag, trunk,
*quando fazer um switch para agregar um branche a outro ou ao trunk,
*como rastrear as as alterações de determinada funcionalidade,
*como “atravessar” funcionalidades para agregar um branch de homologação sem causar riscos
*como manter minha equipe sempre produzindo sem depender da homologação e sem retrabalhos para agregar coisas ao trunk
*uso de integração continua em um trunk estável
*uso de varios trunks para trabalhos paralelos
*como manter uma matriz de ratreabilidade tratando de códigos(atributos e metodos)
Em fim, conversei com um professor e ele disse que devo subir mais o nível para abordar a parte de gestão das demandas para que ao chegar no mais baixo nível, não tenhamos tantos conflitos mas sim, problemas pontuais e medidas pequenas de contorno que afete pouco ou nada o fluxo geral das coisas.
Quero poder agregar tecnicas para tipos de problemas diferentes.
Qualquer contribuição será altamente relevante pessoal!!![/quote]
Este tipo de “controle” de versões é uma necessidade de sua empresa realmente? Digo, determinados clientes estarem usando uma versao enquanto outros usam versoes mais antigas? Isso é necessidade real do negócio ou é problema de gerenciamento e/ou marketing?
Eu trabalho numa emrpesa que tem um numero grande de clientes para as mesmas aplicacao. Os contratos são feitos de forma que não amarrem o cliente a determinadas versoes. É responsabilidade deles manter o sistema atualizado, sempre com a ultima versao disponibilizada para download.
A partir dai nos simplesmente mantemos tags de cada versao e o trunk principal onde a gente trabalha. Se houver alguma correcao urgente, baixamos a tag da versao, fazemos a correcao e disponibilizamos. Mas isso é excepcional, a regra é o que esta no trunk atual vai pra producao o mais rapido possivel. Nós não mantemos um cliente na versao a e outro na b, muito menos planejamos a versao a para dia tal e a b para dia tal do outro mes, a nao ser para efeito de cronograma. Nao existe uma versao b enquanto a A estiver em desenvolvimento.
Usamos um servidor de integracao que a cada commit no repositorio roda os testes unitarios, gera uma versao e coloca num ambiente de homologacao para os testes funcionais. Quando vamos por em producao, simplesmente pegamos o war que esta na homologacao e disponibilizamos pra download.
Se este cenario for possivel para voce, é melhor do que o que voce tem hoje. Tambem não é o ideal, o ideal é nao ter versao, o que vai sendo desenvolvido vai sendo integrado e colocado em producao e pronto.
Se a impossibilidade de voces terem apenas uma versao sendo trabalhada é devido a problemas gerenciais voces (a equipe técnica) devem deixar bem claro que eles estão complicando as coisas e qualquer M… é devido a incapacidade deles de manter uma só versão do produto.