Como devo ramificar e tag antes e depois de um lançamento?

Question

Eu estive pensando sobre o processo de implantação Eu estou usando atualmente, e eu estou querendo saber se há uma boa maneira de lidar com ramificação / etiquetagem o código que vai ser / foi liberado para produção.

Em algum momento eu quero fazer um ramo como o ramo de liberação e fazer quaisquer alterações de última hora para o ramo e liberá-lo. Em seguida, após a liberação que eu quero salvá-lo como o tag.

Para esclarecer, eu estou procurando convenções para nomear, a manipulação dos ramos, e manusear o tagging. Eu também estou querendo saber se existem alternativas para como eu estou falando sobre como lidar com a situação.

• Você nomear os ramos de liberação ou usar o mesmo ramo de lançamento com o novo código de cada vez?
• ramos libertação Delete uma vez que eles existem como tags?
• Como você nomear seus ramos / tags?

Answer 1

sugiro a leitura esta resposta

gestão lançamento no SVN

Basicamente ter um ramo chamado LIBERAÇÃO você pode marcar de lá se você quiser. E manter a versão do código borda do sangramento no tronco

Quanto nomeação liberação está em causa:. Isso depende do que melhor lhe convier e quem são as pessoas vendo o número da versão

Pense em usar MajorRelease.MinorRelease então talvez em algum lugar para o tecnicamente interessado você pode até especificar um número de versão do patch (e.gg aplicativo atualizações automáticas e estadias Major.Minor mesmo).

Major: grandes mudanças -> novas funcionalidades / compatibilidade breaks Menor: Interface compatível (por exemplo, o desempenho) Patch: correções de bugs

Answer 2

Você pode usar as informações aqui como orientação, mesmo se você não estiver usando TFS.

Ramificação Orientação

Answer 3

Existem muitas maneiras de trabalhar. O uso i é o seguinte:

project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
     |
     |- releases //where all release tags are located
     |- daily //where all daily tags are located.

O nomeando que usamos é o seguinte:

• Para ramos que nomear o ramo por aquilo que é as principais tarefas que serão feitas nele. (Por exemplo: admin_module_refactor)
• Para tags que nomear as etiquetas com o número da versão (mayor.minor.micro por exemplo:. 1.0.2) quando correspondem a uma etiqueta de liberação. Ou com a data para tags diárias de trabalho. (Por exemplo: YY_MM_DD)

Para seguir essa estrutura e convenções de nomenclatura, temos um conjunto de ferramentas e scripts que ajuda que trabalham desta forma. Também marcas diárias são gerados por um servidor de compilação todas as noites.

Answer 4

Eu automatizado o processo de compilação usando CruiseControl.Net. Tivemos a corresponder constrói para os números de compilação de modo a versão dll seria 6.5.4.1234. A 6 e 5 sempre iria ser atualizado manualmente quando tivemos maiores e menores lançamentos. O 4 foi atualizado manualmente após uma compilação (eo 1234 foi reposto a 0, em seguida, também). O processo de compilação sempre atualizado o 1234-1235.

Quando lançado a partir de um tronco (a versão seria sempre 6.0.0.x), gostaríamos de ramificar manualmente e chamá-lo Branch_6_0. A filial, então, construir como 6.0.1. Tronco mudaria para 6.1 ou 7.0.

CruiseControl tinha dois modos (dev e teste). Teste foi sempre criado sob demanda e criaria um ramo correspondente à versão de compilação.

Answer 5

Em algum momento eu quero fazer um ramo como o ramo de lançamento e fazer qualquer último minuto muda para o ramo e liberá-lo

Este é o pouco que me preocupa. Normalmente, você vai querer fazer um ramo, fazer todo o seu desenvolvimento sobre ele, então reintegrar esse ramo com o tronco. Crie a sua etiqueta a partir deste ponto no tronco. Se você quiser fazer mais alterações, criar um ramo novo, editar, reintegração e re-lançamento.

Não tente fazer alterações no ramo release como você pode perdê-los, ou ter um momento conturbado fundindo-os de volta para o tronco.

A abordagem alternativa para liberar ramificação é fazer com que todas as alterações de desenvolvimento para tronco e quando estiver pronto, crie um ramo release / tag. Para uma pequena loja de dev, esta é geralmente a maneira mais fácil de ir. (A outra abordagem funciona bem quando você está fazendo grandes mudanças para um produto que todo mundo está fazendo mudanças para também).