Toda a confusão decorre das diferentes semânticas que a MS usa para "Build number" e especialmente "Revision". Os termos significam apenas coisas diferentes.
A maioria das pessoas (inclusive eu) usa um esquema de numeração de versão semântica, onde você obtém um número BUILD mais alto sempre que precisar criar uma nova compilação por qualquer motivo. Para nós, um hotfix é considerado apenas mais uma alteração de código, e a parte BUILD aumenta automaticamente a cada execução de IC. Módulos com o mesmo MAJ.MIN.REV são considerados intercambiáveis e o BUILD informa qual é o mais recente.
A REVISÃO incremental, no entanto, indica um novo ramo de lançamento permanente, é por isso que o colocamos antes do BUILD. A desvantagem dessa abordagem é que podemos obter a seguinte sequência de eventos:
- confirmar número 4711: Alice adicionou o recurso A
- O IC produz a compilação 1.2.3.100
- confirmar número 4712: recurso modificado Bob B
- confirmar número 4713: Alice corrigiu o recurso A (o "hotfix")
- O IC produz a compilação 1.2.3.101
Como você pode ver, o hotfix não é a única alteração contida na próxima compilação, também a modificação de Bob se torna parte dessa compilação. Se você quiser estabilizar a ramificação atual, poderá ter problemas, pois nunca poderá ter certeza se Bob acabou de adicionar um monte de bugs.
A Microsoft usa os dois termos de maneira diferente. O número BUILD não é incrementado automaticamente; em vez disso, pode ser considerado como uma ramificação de liberação, para congelar o código usado para uma versão específica do código. A REVISION indica alterações "quentes" adicionais aplicadas a essa ramificação BUILD. A sequência seria, portanto, a seguinte:
- confirmar número 4711: Alice adicionou o recurso A ao tronco / mestre
- Carl cria ramo de construção
1.2.100
- O IC produz a compilação 1.2.100.0
- confirmar número 4712: Bob modificou o recurso B no tronco / mestre
- confirmar número 4713: Alice corrigiu o recurso A na
1.2.100
ramificação
- O IC produz a compilação 1.2.100.1
O termo REVISÃO pode se referir a
- uma revisão do produto (é assim que a maioria das pessoas a usa)
- uma revisão de uma compilação diária específica (é o que a MS faz)
A principal diferença entre os dois processos é se você deseja ou não aplicar hotfixes às compilações de IC e, portanto, em que ponto do processo a ramificação é feita. Esse aspecto se torna importante quando você deseja escolher uma compilação específica a qualquer momento após todos os testes terem sido bem-sucedidos e promover exatamente essa versão para a próxima versão oficial do seu produto.
No nosso caso, a ferramenta de IC cria uma tag de repositório, para que sempre tenhamos as informações necessárias prontas para uso, quando necessário. Com o SVN, torna-se ainda mais simples, porque as tags e ramificações são implementadas exatamente da mesma maneira - uma tag nada mais é do que uma ramificação localizada abaixo /tags
.
Veja também
Na seção Perguntas frequentes na estratégia de ramificação do TFS :
Em que ramo devo corrigir o ticket P1 (hotfix)?
O P1 deve ser corrigido na ramificação mais próxima da base de código em execução na produção. Nesse caso, o P1 deve ser corrigido no ramo Prod. Ao aplicar a correção em qualquer outra ramificação e implementar as alterações na produção, você corre o risco de liberar código semiacabado ou não testado das iterações subseqüentes.
Agora você pode argumentar se é seguro trabalhar diretamente contra o ramo Prod, pense novamente, um P1 que requer atenção imediata não deve ser um problema fundamental no sistema. Caso seja um problema fundamental, ele deve ser adicionado ao backlog do produto, pois pode exigir análises e discussões adicionais com o cliente.
Outra boa leitura é o guia de ramificação do TFS