Como fazer a Integração Contínua quando as ramificações de desenvolvimento separadas têm diferentes datas de implementação de produção?

5

Digamos que você tenha três ramificações de desenvolvimento ao mesmo tempo (dev 1, dev 2, dev 3), cada filial trabalhando em diferentes recursos para um determinado produto de software.

Se eu entendi a integração contínua corretamente, essas linhas de desenvolvimento precisariam verificar constantemente o código de volta para uma linha principal compartilhada (depois de passar pelo teste), com o código da linha principal compartilhado sendo mesclado em cada ramificação do desenvolvedor regularmente.

O que acontece quando um dos ramos dev (dev 1) está pronto para uma implementação de produção, e os outros ramos dev (dev 2, dev 3) não são? Se o código de ramificação dev 1 for empurrado através do UAT e dentro de Production, todo o código das ramificações dev 2 e dev 3 que foram 'continuamente integradas' no dev 1 também será empurrado para o Prod, mesmo com recursos em dev 2 e dev 3 pode não estar pronto (ou programado) para lançamento.

Como posso evitar esse problema enquanto ainda aderir à Integração Contínua?

    
por Callum 27.10.2016 / 07:12
fonte

3 respostas

3

Além de Vlad, você configuraria o (s) ambiente (s) de teste para cada ramificação. O IC seria então configurado para enviar as alterações feitas para o ramo A para o Teste A e o Ramo B para o Teste B.

Um ramo pode conter entre 1 e n recursos. Quanto menos você tiver em um ramo, menor será o impacto se deslizar.

As alterações permanecem nas filiais até que sejam liberadas.

Uma vez feito o Release A, você mesclará o novo Main (contendo o release A) no Branch B e continuará trabalhando no Release B.

O único limite para o número de filiais que você pode executar simultaneamente é sua equipe / infraestrutura. Um dev pode, teoricamente, ser atribuído a mais de um recurso isolado em filiais separadas simultaneamente. Eu recomendo fazer isso? Provavelmente não. Conclua um trabalho de cada vez. Se, no entanto, houver uma mudança nas prioridades, um ramo pode ser estacionado enquanto outro é trabalhado.

    
por 27.10.2016 / 07:58
fonte
2

Esta afirmação está errada: "cada uma das linhas de desenvolvimento precisa verificar constantemente o código de volta para uma linha principal compartilhada". A razão para introduzir ramificações é não mesclar o código instável ao main. Por que você realmente precisa de três ramificações dev se estiver se fundindo imediatamente?

O CI não incentiva você a sacrificar a qualidade pela frequência das implantações. Ele faz com que você implante o mais rápido possível, mas não mais rápido .

    
por 27.10.2016 / 07:45
fonte
0

Como @vlad indicou que o problema é com "cada uma das linhas de desenvolvimento precisaria checar constantemente o código de volta para uma linha principal compartilhada"

Veja o que você deve considerar:

  • crie uma ramificação de desenvolvimento conforme necessário
  • trabalhe no ramo e envie o commit nesse ramo
  • buscar as alterações mais recentes do mestre (para atualizar seu mestre, NÃO sua filial)
  • rebase ou mescle o seu branch contra master, mas fique no branch
  • empurrar a ramificação atualizada para remoto
  • continuar o trabalho, rebasing contra master e push commits durante o desenvolvimento
  • quando o trabalho estiver concluído, mesclar ao mestre e liberar.
por 27.10.2016 / 13:07
fonte