Melhores práticas para controle de origem e correções de bugs

Question

Se for necessário emitir um patch bug que não inclui desenvolvimento atual que tenha sido cometido, ou quaisquer alterações de sua versão atual, o que deve ser feito para tornar o processo mais seguro e com menor sobrecarga?

No momento, estamos usando o Subversion para o nosso controle de origem em um (3 desenvolvedores) pequena equipe de desenvolvimento, principalmente no Visual Studio 2008. Prevemos que a equipe pode grupo de 8 desenvolvedores durante o próximo ano, e para qualquer suporte versão anterior para se tornar mais complicado. Enquanto a maioria dos clientes estão na versão atual, alguns são mais para trás.

Answer 1

O controle de origem pode lidar com isso muito facilmente, e foi projetado para isso.

Quando você alcança o período de estabilização de sua liberação de um ramo deve ser feito. É importante que você não começar qualquer trabalho na próxima versão antes que isso seja feito.

Qualquer correções de bugs para essa autorização deve ser feito nesse ramo. Isso evita que o novo código a partir de um lançamento de poluir a correção de bug. Uma vez que a correção de bug é feito, então você pode mesclar que a mudança para baixo para o tronco, e quaisquer outros lançamentos como necessário.

Não se esqueça de colocar o número bug no comentário, pois isso fará com que se manter a par de commits mais fácil.

Answer 2

Como sobre:. Um ramo per versão principal, com correções de bugs aplicada ao ramo (es), conforme necessário, e também aplicados (ou fundidos) volta para o trunk

Answer 3

Onde eu trabalho, temos vários projetos que trabalham simultaneamente. Para evitar este problema, temos várias variantes do código-fonte. Por exemplo, a primeira versão é Variante 1.0. Nós criamos um ramo fora desta versão, digamos, Variant 2.0, para todo o desenvolvimento futuro. Se nós precisamos fazer uma correção de bug, fazemo-lo na principal Variant, que é atualmente 1.0 e pode liberar isso. Quando Variant 2.0 está pronto para ir para a produção, nós mesclá-lo com tudo o que está no ramo principal (neste caso, 1,1) e que se torna o novo tronco principal. Em um ponto, tivemos 4 ramos em execução ao mesmo tempo.

Fundir o código pode ser demorado, e você tem que ter cuidado para não introduzir novos bugs durante a fusão, mas se você tiver uma ferramenta de comparação de código decente disponível, então não deve ser muito ruim. Fizemos um uma mesclagem tempo atrás usando Beyond Compare em um diretório de origem 10.000 arquivo, e levou uma única manhã.