Como você lida com a tensão entre refatoração ea necessidade de fusão?

Question

A nossa política quando entregar uma nova versão é a de criar uma filial em nosso VCS e manipulá-lo à nossa equipe de QA. Quando este último dá luz verde, nós marcar e soltar o nosso produto. O ramo é mantido para receber (apenas) correções de bugs, para que possamos criar lançamentos técnicos. Essas correções de bugs são posteriormente incorporada no tronco.

Durante este tempo, o tronco vê o trabalho de desenvolvimento principal, e é potencialmente sujeito a refatoração alterações.

O problema é que há uma tensão entre a necessidade de ter um tronco estável (de modo que a fusão de correções de bugs sucesso - que geralmente não podem se o código tem sido exemplo extraído para outro método, ou movido para outra classe) ea necessidade de refatorar-lo ao introduzir novos recursos.

A política em nosso lugar é a de não fazer qualquer refatoração antes passou tempo suficiente eo ramo é suficiente estável. Quando este for o caso, pode-se começar a fazer mudanças refatoração no tronco, e correções de bugs estão a ser cometidos manualmente tanto no tronco e do ramo.

Mas isso significa que programadores devem esperar algum tempo antes de cometer no tronco qualquer alteração refatoração, porque isso poderia quebrar a fusão posterior do ramo ao tronco. E ter a bugs porta manualmente a partir da ramificação para o tronco é doloroso. Parece-me que este desenvolvimento cabazes ...

Como você lida com essa tensão?

Graças.

Answer 1

Este é um problema prático real. E fica ainda pior se você tiver várias versões você precisa de apoio e têm ramificações para cada um. Ainda pior ainda se você tem um verdadeiro ramo de R & D também.

A minha preferência era para permitir que o tronco principal para proceder à sua taxa normal e não se segurar, porque em um ambiente onde tempos de libertação foram importantes comercialmente eu nunca poderia discutir o caso que devemos permitir que o código para estabilizar ( "o que, quer dizer que você lançou em um estado instável? ").

A chave era ter certeza de que os testes de unidade que foram criados para as correções de bugs foram transferida através quando o bug foi migrado para o ramo principal. Se suas novas alterações de código são genuinamente just-factoring re, em seguida, os antigos testes devem funcionar igualmente bem. Se você alterações são tais que eles já não são válidos, então você não pode simplesmente porta-lo a corrigir em qualquer caso, e você precisa ter alguém pensar muito sobre a correção no novo fluxo de código.

Depois de alguns anos gerenciando este tipo de problema eu concluí que você provavelmente precisará de 4 código córregos no mínimo para fornecer suporte adequado e cobertura, e uma coleção de processos rigorosos bonitas para gerenciar o código através deles. É um pouco como o problema de ser capaz de desenhar qualquer mapa em 4 cores.

Eu nunca encontrei qualquer boa literatura sobre o assunto. Ele será inevitavelmente ligada à sua estratégia de lançamento e os SLAs que você assina com seus clientes.

Adenda: Eu também deve mencionar que foi necessário escrever o ramo fusão como metas específicas para o calendário de lançamentos do ramo principal. Não subestimar a quantidade de trabalho que pode ser implicado em trazer seus ramos juntos, se você tem uma coleção de desenvolvedores que trabalham duro fazendo seu trabalho características de execução.

Answer 2

Onde eu trabalho, criamos temporária, de curta duração (menos de dia - algumas semanas) ramos de trabalho para cada mudança não-trivial (recurso Adicionar ou bugfix). Tronco é estável e (idealmente) potencialmente libertável todo o tempo; única feito itens ficar colada com ele. Tudo cometidos a partir tronco se fundiram para os ramos de trabalho todos os dias; isso pode ser amplamente automatizadas (usamos Hudson, Ant e Subversion). (Este último ponto, porque é geralmente melhor para resolver quaisquer conflitos cedo ou mais tarde, é claro.)

O uso modelo que corrente foi largamente influenciada por uma excelente artigo ( que eu tenho ligado antes ) por Henrik Kniberg: Controle de Versão para vários Agile Teams .

(No nosso caso, temos duas equipes trabalhando em uma base de código, mas eu vim a pensar que este modelo pode ser benéfico mesmo com uma equipe).

Há alguma sobrecarga sobre a ramificação extra e fusão, mas não muito, realmente, uma vez que você se acostumar com isso e ficar melhor com as ferramentas (por exemplo svn merge --reintegrate é útil). E não, eu não criar um ramo temporário sempre, por exemplo, para menores refatorações de baixo risco (não relacionadas com os principais itens atualmente em trabalho) que podem ser facilmente preenchido com um commit ao tronco.

Nós também mantemos um ramo versão mais antiga em que bugs críticos são fixos ao longo do tempo. Na verdade, pode ser manual (por vezes tedioso) trabalho fusão se alguma parte específica do código evoluiu no tronco significativamente em comparação com o ramo. (Este espero torna-se menos de um problema enquanto nos movemos para incrementos continuamente liberando a partir do tronco (internamente), e deixando de marketing e produto de gestão de decidir quando querem fazer um lançamento externo.)

Eu não tenho certeza se isso responde a sua pergunta diretamente, ou se você pode aplicar isso em seu ambiente (com a equipe de QA separado e tudo) -, mas pelo menos eu posso dizer que a tensão que você descrever não existe para nós e nós somos livres para refatorar sempre. Boa sorte!

Answer 3

Eu acho que a tensão pode ser tratada através da adição seguintes ingredientes para o seu processo de desenvolvimento:

1. A integração contínua
testes funcionais
2. Automated (Eu presumo que você já contam com testes de unidade)
3. entrega automática

Com a integração contínua, cada submissão implica uma construção onde todos os testes de unidade são executados e estão alarmados se alguma coisa der errado. Você começa a trabalhar mais com a cabeça e você está menos propenso a ramificação da base de código.

Com testes funcionais automatizados, você é capaz de testar a sua aplicação com o clique do botão. Geralmente, uma vez que estes testes levam mais tempo, estes são executados todas as noites. Com isso, o papel clássico de versionamento começa a perder a importância. Você não faz a sua decisão sobre quando liberar baseado na versão e sua maturidade, é mais do decisão de negócios. Se você tiver implementado unidade e testes funcionais e sua equipe está submetendo código testado, a cabeça deve sempre no estado que pode ser liberado. Erros são continuamente descobertos e corrigidos e solte entregue, mas isso não é qualquer processo mais cíclica, é o contínuo.

Você provavelmente terá dois tipos de detratores, já que isso implica mudar algumas práticas longa enraizadas. Em primeiro lugar, a mudança de paradigma da entrega contínua parece contra-intuitivo para os gestores. “Não estamos arriscando para enviar um grande erro?” Se você dar uma olhada em distros Linux ou Windows, este é exatamente o que eles estão fazendo: empurrando lançamentos para com os clientes. E uma vez que você contar com a suíte de testes automatizados, os perigos são ainda mais reduzida.

Em seguida, a equipe de QA ou departamento. (Alguns argumentam que o problema é a sua existência em si!) Eles serão geralmente aversivo para a automatização de testes. Significa aprender ferramenta nova e às vezes complicado. Aqui, o melhor é pregar por fazê-lo. Nossa equipe de desenvolvimento começou a trabalhar em integrações contínuas e ao mesmo tempo a escrever o conjunto de testes funcionais com selênio . Quando a equipe de QA viu a ferramenta em ação, era difícil se opor a sua implementação.

Finalmente, o thurth é que o processo que eu descrevi não é tão simples como addig 3 ingredinents para o seu processo de desenvolvimento. Isso implica uma profunda alteração na forma como você desenvolve software.

Answer 4

Talvez Git (ou outros DVCS) são melhores em lidar com fusões de graças de código atualizados para o fato de que eles (realmente) gerenciar as mudanças em vez de arquivos basta comparar ... Como Joel diz :

Com o controle de versão distribuído, fusões são fáceis e trabalhar bem. Então você pode realmente ter um ramo estável e um ramo de desenvolvimento, ou criar filiais de vida longa para a sua equipe de QA onde eles testam coisas antes da implantação, ou você pode criar ramos de curta duração para testar novas idéias e ver como eles funcionam.

Ainda não tentei, embora ...

Answer 5

Onde eu trabalho, mantemos com a refatoração no ramo principal. Se as fusões ficar complicado, eles só têm de ser tratadas numa base ad-hoc, todos eles são capaz de fazer, mas, ocasionalmente, levar um pouco de tempo.

Answer 6

Talvez nosso problema vem do fato de que temos filiais que devem ter uma vida bastante longa (até 18 meses), e há muitas correções que precisam ser feitas contra eles.

Certificar-se de que só se ramificam a partir do código extremamente estável provavelmente ajudaria, mas não vai ser tão fácil ...: (