Como a integração contínua pode ser dimensionada para projetos / equipes muito grandes?

Tradicionalmente, os sistemas de CI monitoram apenas a qualidade do código em uma ramificação de integração, sinalizando quando ocorrem regressões. A intervenção humana é necessária para reparos.

À medida que o número de desenvolvedores que trabalham no mesmo ramo aumenta, aumenta o risco de quebras / bloqueios. Eventualmente, chega-se a um ponto em que, em média, quando uma quebra é corrigida, uma nova aparece - o progresso no ramo se torna efetivamente insignificante.

Dividir em várias equipes, cada um trabalhando em um ramo de integração separado que seria mesclado em um momento posterior pode ajudar, mas estende bastante a duração do projeto, uma vez que simplesmente atrasa a integração necessária para um momento posterior ao adicionar agitação / ruído / departamento técnico relacionado a a integração parcial de ramificação individual é mesclada. Os custos também aumentam devido às configurações de IC para cada uma das filiais, cada uma com seus próprios recursos de construção / controle de qualidade, etc. E a qualidade geral não é necessariamente melhor.

A escalabilidade é, na melhor das hipóteses, duvidosa.

Existe um método para fazer com que projetos tão grandes sejam realmente dimensionados?

Sim, mas é impedindo o máximo possível as coisas que você menciona na sua pergunta. Você está certo que existem tantos desenvolvedores que podem trabalhar no mesmo código antes que as coisas se tornem incontroláveis. Você precisa de alguém ou algo que tenha uma visão geral de todas as alterações e garanta que a integração funcione bem e que a regressão não ocorra. É difícil escalar se tudo acontecer em um repositório.

Antes de iniciar qualquer trabalho, é necessário separar a funcionalidade de forma que as coisas possam ser integradas posteriormente com pouco ou nenhum esforço. Isso significa que você deseja dividir a funcionalidade em partes independentes ou pelo menos ter o mínimo de dependências possível. Como você faz isso depende muito do produto que está desenvolvendo. No passado, a separação de funcionalidade era feita criando diferentes bibliotecas. A desvantagem disso é que você precisa de um bom método de gerenciamento dessas bibliotecas. Versões antigas do Windows, por exemplo, tinham um sistema de gerenciamento de bibliotecas ruim que causava a infame DLL Hell . Atualmente, os microsserviços são (se tornando) uma maneira popular de fazer isso, embora isso também tenha suas desvantagens (por exemplo, sobrecarga de comunicação, mais serviços para monitorar)

Se a separação com base na funcionalidade for difícil, outra opção pode ser separar o desenvolvimento no tempo. Em vez de várias equipes trabalharem simultaneamente em muitos recursos diferentes, você tem uma equipe que trabalha apenas em um ou alguns recursos por vez.

Quando a separação do trabalho não for possível, você precisará de ferramentas e testes que garantam o alinhamento das coisas. O teste automatizado de unidade e integração pode ser uma grande ajuda aqui, mas, em última análise, haverá limites para o tamanho de um projeto ou equipe para ser viável.

À medida que o número de desenvolvedores que trabalham no mesmo ramo aumenta, aumenta o risco de quebras / bloqueios. Eventualmente, é atingido um ponto em que, em média, quando uma quebra é corrigida, uma nova aparece

Embora a primeira parte da frase esteja provavelmente estatisticamente correta, eu discordo da segunda.

As ramificações de IC e integração não podem derrotar o GIGO (lixo em lixo). Se os desenvolvedores não tiverem disciplina, você terminará em uma ramificação interrompida, mas os testes da ramificação de integração devem funcionar apenas como a barreira do lat, não a primeira.

Os desenvolvedores devem usar padrões de codificação adequados, revisões de código, testes de unidade local e, possivelmente, testes de ramificação pré-integração para tornar menos prováveis ​​as colisões.

Estou trabalhando diariamente em um sistema desse tipo com centenas de colaboradores e, surpreendentemente, é incomum vê-lo travar.

Não tenho dados suficientes, mas pode ser verdade que o custo é alto; por outro lado, é difícil julgar o custo alternativo da integração e bugs tardios.

Outra abordagem é mudar para um sistema de IC diferente e não tradicional, capaz de impedir regressões , identificando e rejeitando as alterações candidatas ofensivas antes de sua consolidação, em vez de detectar regressões e aguardar recuperação enquanto o desenvolvimento na ramificação está bloqueado. Eu gosto de chamar esse sistema de um sistema de CI sem bloqueio .

Simplesmente aumentar os requisitos de verificação de pré-confirmação executados pelo desenvolvedor na tentativa de reduzir as regressões de ramificações não é suficiente para essa garantia. Na verdade, pode causar um aumento na taxa de regressão : tempos de verificação mais longos => maior número de alterações verificadas simultaneamente isoladamente (portanto, não são responsáveis ​​umas pelas outras) => maior risco de conflitos e interferências funcionais. Estou explicando isso com mais detalhes na extensão da cobertura de verificação pré-confirmação deve aumentar nosso mito de estabilidade de ramificação .

A ferramenta de IC também precisa ser capaz de operar em escala, é claro. E essas ferramentas existem, consulte Existe uma ferramenta de IC que não garanta regressões no nível de qualidade da filial?

^{Divulgação: sou afiliado à empresa mencionada nos links acima.}