Lidar com vários ramos em integração contínua

Tenho lidado com o problema de escalonamento de CI na minha empresa e, ao mesmo tempo, tentando descobrir qual abordagem tomar quando se trata de CI e várias filiais. Há uma questão semelhante em stackoverflow, Multiple feature branches e integração contínua . Comecei um novo porque gostaria de obter mais discussão e fornecer algumas análises sobre a questão.

Até agora descobri que existem 2 abordagens principais que posso adotar (ou talvez algumas outras ???).

• Vários conjuntos de trabalhos (falando sobre Jenkins / Hudson aqui) por filial
  • Escreva ferramentas para gerenciar os trabalhos extras
    • Criar / modificar / excluir trabalhos em massa
    • Configurações personalizadas para cada trabalho por filial (url SCM, duplicações de repositórios de gerenciamento de depósito)
    • Alguns exemplos de pessoas lidando com esse problema com ferramentas shell, scripts de formigas e Jenkins CLI. Vejo:
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729. html
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. Configurar ou criar um trabalho hudson automaticamente
  • Irá causar mais carga no seu cluster CI
  • O ciclo de feedback para desenvolvedores fica lento (se a infraestrutura não puder lidar com a nova carga)
• Vários conjuntos de trabalhos por 2 ramos (dev e estável)
  • Gerenciar os dois conjuntos manualmente (se você alterar a configuração de um trabalho, certifique-se de alterar no outro ramo)
    • PITA, mas pelo menos tão poucos para gerenciar
  • Outros branches extras não terão um conjunto de testes completo antes de serem enviados para o dev
  • Devs insatisfeitos. Por que um desenvolvedor deveria se preocupar com problemas de escala de CI? Ele tem um pedido simples, quando eu ramificar gostaria de testar meu código. Simples.

Então, parece que se eu quiser fornecer aos desenvolvedores CI para seus próprios branches personalizados, preciso de ferramentas especiais para Jenkins (API ou shellscripts ou algo assim?) E lidar com o dimensionamento. Ou posso dizer a eles para mesclar com mais frequência ao DEV e viver sem CI em branches personalizados. Qual você escolheria ou existem outras opções?

Quando você fala sobre escalonamento de CI, você está realmente falando sobre escalonar o uso de seu servidor de CI para lidar com todos os seus branches de recursos junto com sua linha principal. Inicialmente, isso parece uma boa abordagem, já que os desenvolvedores em uma filial obtêm todas as vantagens do teste automatizado que as tarefas de CI incluem. No entanto, você encontra problemas para gerenciar as tarefas do servidor de CI (como descobriu) e, mais importante, você não está realmente fazendo CI. Sim, você está usando um servidor de CI, mas não está integrando continuamente o código de todos os seus desenvolvedores.

Executar CI real significa que todos os seus desenvolvedores estão se comprometendo regularmente com a linha principal. Fácil de falar, mas o difícil é fazê-lo sem quebrar seu aplicativo. Recomendo enfaticamente que você dê uma olhada na Entrega contínua , especialmente na seção Mantendo seu aplicativo liberável no Capítulo 13: Gerenciando componentes e dependências . Os pontos principais são:

• Oculte a nova funcionalidade até que seja concluída (AKA Feature Toggles )
• Faça todas as alterações de forma incremental como uma série de pequenas alterações, cada uma delas liberável.
• Use ramificação por abstração para fazer alterações em grande escala na base de código.
• Use componentes para desacoplar partes de seu aplicativo que mudam em taxas diferentes.

Eles são bastante autoexplicativos, exceto ramo por abstração. Este é apenas um termo chique para:

1. Crie uma abstração sobre a parte do sistema que você precisa alterar.
2. Refatore o resto do sistema para usar a camada de abstração.
3. Crie uma nova implementação, que não faça parte do caminho do código de produção até ser concluída.
4. Atualize sua camada de abstração para delegar à sua nova implementação.
5. Remova a implementação antiga.
6. Remova a camada de abstração se ela não for mais apropriada.

O parágrafo a seguir da seção Ramificações, fluxos e integração contínua no Capítulo 14: Controle de versão avançado resume os impactos.

A abordagem incremental certamente requer mais disciplina e cuidado - e de fato mais criatividade - do que criar uma filial e mergulhar de cabeça na reconstrução e no desenvolvimento de novas funcionalidades. Mas isso reduz significativamente o risco de suas alterações interromperem o aplicativo e economizará muito tempo para você e sua equipe mesclar, consertar quebras e colocar seu aplicativo em um estado implantável.

É preciso uma grande mudança de mentalidade para desistir dos branches de recursos e você sempre terá resistência. Na minha experiência, essa resistência é baseada em desenvolvedores que não se sentem seguros ao comprometer o código na linha principal e essa é uma preocupação razoável. Isso, por sua vez, geralmente resulta da falta de conhecimento, confiança ou experiência com as técnicas listadas acima e, possivelmente, com a falta de confiança com seus testes automatizados. O primeiro pode ser resolvido com treinamento e suporte do desenvolvedor. O último é um problema muito mais difícil de lidar, porém a ramificação não fornece nenhuma segurança real extra, ela apenas adia o problema até que os desenvolvedores se sintam confiantes o suficiente com seu código.

Eu criaria trabalhos separados para cada filial. Já fiz isso antes e não é difícil de gerenciar e configurar se você configurou Hudson / Jenkins corretamente. Uma maneira rápida de criar vários trabalhos é copiar de um trabalho existente que tenha requisitos semelhantes e modificá-los conforme necessário. Não tenho certeza se você deseja permitir que cada desenvolvedor configure seus próprios trabalhos para seus próprios ramos, mas não é muito trabalho para uma pessoa (ou seja, um gerente de compilação) gerenciar. Uma vez que as ramificações personalizadas foram mescladas em ramificações estáveis, os trabalhos correspondentes podem ser removidos quando não forem mais necessários.

Se estiver preocupado com a carga no servidor de CI, você pode configurar instâncias separadas do CI ou mesmo escravos separados para ajudar a equilibrar a carga em vários servidores. Certifique-se de que o servidor em que está executando o Hudson / Jenkins é adequado. Eu usei o Apache Tomcat e apenas tive que garantir que ele tivesse memória e capacidade de processamento suficientes para processar a fila de construção.

É importante deixar claro o que você deseja alcançar usando CI e então descobrir uma maneira de implementá-lo sem muito esforço manual ou duplicação. Não há nada de errado em usar outras ferramentas externas ou scripts que são executados por seu servidor de CI que ajudam a simplificar seu processo geral de gerenciamento de build.

Eu escolheria dev + branches estáveis. E se você ainda quer ramificações personalizadas e tem medo da carga, então por que não mover essas ramificações personalizadas para a nuvem e deixar que os desenvolvedores gerenciem eles mesmos, por exemplo http://cloudbees.com/dev.cb Esta é a empresa onde Kohsuke está agora . Há um Eclipse Tooling também, então se você estiver no Eclipse, você o terá totalmente integrado ao dev env.

Na verdade, o que é realmente problemático é o isolamento de construção com ramificações de recursos. Em nossa empresa, temos um conjunto de projetos maven separados, todos parte de uma distribuição maior. Esses projetos são mantidos por equipes diferentes, mas para cada distribuição, todos os projetos precisam ser liberados. Uma featurebranch agora pode se sobrepor de um projeto a outro e é aí que o isolamento da construção fica doloroso. Existem várias soluções que tentamos:

• criar repositórios de instantâneos separados no nexo para cada ramo de recurso
• compartilhar repositórios locais em escravos dedicados
• use o repository-server-plugin com os repositórios upstream
• construir tudo dentro de um trabalho com um repositório privado

Na verdade, a última solução é a mais promissora. Todas as outras soluções carecem de uma ou de outra forma. Junto com o plugin job-dsl, é fácil configurar um novo branch de recurso. simplesmente copie e cole o script bacana, adapte os ramos e deixe o trabalho inicial criar os novos trabalhos. Certifique-se de que a tarefa de propagação remova tarefas não gerenciadas. Em seguida, você pode escalar facilmente com ramificações de recursos em diferentes projetos de maven.

Mas, como Tom disse bem acima, seria melhor superar a necessidade de branches de recursos e ensinar os desenvolvedores a integrar de forma limpa, mas esse é um processo mais longo e o resultado não é claro com muitas partes do sistema legado que você não vai tocar mais.

meus 2 centavos