Existe uma ferramenta de IC que não garanta regressões no nível de qualidade da filial?

Tradicionalmente, os sistemas de CI executam apenas o monitoramento dos níveis de qualidade em uma ramificação de integração, executando verificações de controle de qualidade na base de código em que as alterações já foram confirmadas, observando as regressões e enviando notificações para intervenção humana.

Mas quando essas regressões são detectadas, a ramificação já está com problemas pelo menos desde que a respectiva verificação de controle de qualidade foi iniciada e permanecerá nesse estado (ou até piorará!) Até que todos os culpados sejam identificados, reparos para eles cometidos e uma nova verificação de controle de qualidade confirma que o nível de qualidade da filial foi restaurado. O ramo pode ser considerado bloqueado para desenvolvimento normal durante todo esse tempo.

Existe uma ferramenta de IC capaz de realmente impedir que tais regressões aconteçam, que executariam verificações de controle de qualidade pré-confirmação e permitissem confirmações somente quando a base de código atualizada com os respectivos comprometimentos passariam essas verificações de controle de qualidade pré-confirmação, garantindo assim um mínimo nível de qualidade da filial?

Atualização: pressupõe-se que verificações automatizadas de controle de qualidade adequadas, com cobertura adequada, para poder detectar as respectivas regressões, estejam disponíveis para invocação pelas ferramentas de IC.

Pelo que sei, você está procurando uma ferramenta que rejeite confirmações que quebram a compilação - uma ferramenta de IC provavelmente não será capaz de impedir regressões corrigindo seu código, mas pode impedi-lo de adicionar código incorreto para o repositório.

Atlassian tem algumas aplicações interessantes de ganchos Git :

Os ganchos de pré-recepção do servidor são um complemento especialmente poderoso para a integração contínua, porque eles podem impedir que os desenvolvedores pressionem o código para mestre, a menos que o código atenda a certas condições - como guardiões ninjas de elite, protegendo-o de códigos incorretos.

Se você estiver usando o Git, os ganchos são muito poderosos (e existem ganchos semelhantes para SVN , Mercurial e outros sistemas de controle de versão), e você pode achar útil usá-los para executar verificações pré-confirmação.

A documentação do Git tem uma página sobre a criação de um gancho para rejeitar impulsos se eles não atenderem a um determinado critério que pode ser facilmente adaptado a esse caso de uso.

No entanto, muitas pessoas argumentam que rejeitar confirmações é uma má idéia em uma featurefilial - você estará perdendo tempo lutando contra seu sistema de CI quando a compilação for interrompida por algum motivo, em vez de realmente consertar o bug.

Na masterramificação, poderia fazer sentido rejeitar mesclagens quebradas, porque você pode querer garantir que ela sempre seja criada. Para uma featurefilial, você vai inevitavelmente quebrar coisas, e uma vez que o código não está entrando em produção agora , faz mais sentido apenas para avisá-lo do que realmente rejeitar sua submissão por completo.

Nenhuma ferramenta poderia garantir nenhuma regressão - isso depende muito mais de seus testes do que a ferramenta que os executa. No entanto, você pode ajudar a impedir que regressões capturadas entrem no ramo de integração. Você pode fazer isso com ganchos de pré-confirmação, mas geralmente é mais fácil com solicitações pull (que esperamos que você já esteja usando para revisão de código por pares).

Se uma ramificação estiver atualizada com o upstream (onde o PR está sendo mesclado) e seus testes forem aprovados, eles ainda serão aprovados após a mesclagem; o estado da ramificação de destino após a mesclagem corresponderá ao estado da ramificação de origem antes da mesclagem.

Geralmente, não é particularmente difícil (dependendo das ferramentas usadas) indicar se a ramificação de origem em um PR está atualizada com o destino e se ela tem uma compilação de IC aprovada. Você pode usar isso como um requisito (por política e / ou imposto em software) para mesclar a solicitação de recebimento.

As verdadeiras ferramentas de integração contínua (em oposição a apenas testes contínuos) como Reitveld e Zuul podem ajudar, embora sejam tão boas quanto os testes que você escreve e as revisões de código que você faz.

Use o GitLAB, você pode definir configurações do projeto para permitir apenas uma mesclagem quando o pipeline for bem-sucedido, para ter uma integração verdadeiramente contínua, combinando isso com a adição de seu controle de qualidade à lista de aprovações de mesclagem e com ambientes dinâmicos, você pode ter garantia de qualidade antes de mesclar com o mestre.

O ApartCI é um sistema de CI projetado exatamente para evitar regressões, garantindo assim um nível de qualidade de filial simples ou crescente. Ainda em beta.

Ele orquestra as verificações centralizadas de pré-confirmação de maneira a garantir que uma alteração seja confirmada somente depois de verificada, juntamente com todas as outras alterações confirmadas antes, para atender ou exceder o nível de qualidade da filial mais recente.

Essa é a principal diferença em comparação com as verificações de pré-confirmação tradicionais orientadas pelo desenvolvedor, geralmente feitas em paralelo, o que deixa espaço para regressões causadas por alterações interferentes que nunca foram testadas juntas.

A ferramenta também foi projetada para ser dimensionada com facilidade - capaz de sustentar taxas muito altas de alterações de candidatos recebidos e oferecer suporte a 100s / 1000s de desenvolvedores que trabalham no mesmo ramo de integração.

Isenção de responsabilidade: sou o autor da ferramenta e o fundador da empresa que a oferece. Desculpas pelo anúncio.