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


10

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.


Eu fico pensando sobre a maneira correta de entender essa pergunta (e sua própria recomendação em sua própria resposta). Se eu substituísse "monitoramento" por "após os fatos" e "impedir" por "impedi-los de acontecer", seria mais ou menos a mesma pergunta? Além disso, talvez você possa adicionar um exemplo de cenário para explicar a diferença?
Pierre.Vriens

@ Pierre.Vriens Isso é melhor?
Dan Cornilescu

Respostas:


6

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.


Bem, de que serve uma imagem sw que cria, mas o DOA é um teste em potencial? Os desenvolvedores não podem testar suas alterações de código, mesmo que construam, para que fiquem igualmente bloqueados. Portanto, em geral, eu estenderia a rejeição de confirmação a qualquer coisa que falhe em uma verificação mínima de controle de qualidade, escolhida equilibrando 2 requisitos conflitantes: o mais alto possível para maximizar o número de desenvolvedores protegidos contra bloqueio e o mais baixo possível, de modo que a verificação de controle de qualidade atrase retardar demais o processo.
precisa

Um exemplo disso pode ser o modelo de solicitação de recebimento, no qual você pode colocar certas restrições sobre se uma solicitação de recebimento pode ser mesclada ou não. Por exemplo, nós (minha empresa) usamos o Atlassian Bitbucket Server e há opções para exigir pelo menos N número de aprovações e número X de construções passadas para a ramificação especificada antes que uma solicitação de recebimento seja mesclada. Isso não a rejeita completamente. Mas impede a fusão acidental quando os testes falham ou outros olhos ainda não viram o código.
Andy Shinn

@ AndyShinn: Sim, acho isso bastante útil - o GitHub também oferece ramificações protegidas e verificações de solicitações de recebimento , que geralmente são úteis.
precisa

11
Um argumento para permitir código quebrado nas ramificações dos recursos é que ele permite que os desenvolvedores enviem o código no qual estão trabalhando no repositório, mesmo que ainda não esteja pronto. Isso pode ser útil para o compartilhamento de código com outras pessoas, para revisões antecipadas de código / arquitetura antes que as coisas estejam prontas, para ajudar a solucionar problemas de depuração ou para alguém que está saindo de férias para colocar um trabalho parcialmente realizado, onde outras pessoas possam acessá-lo. Para ramificações de recursos, eu colocaria apenas coisas como linters e como ganchos de pré-confirmação.
precisa saber é

2

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.


"Se um ramo está atualizado com o upstream (onde o PR está se mesclando) e seus testes passam, eles ainda serão aprovados após a mesclagem" - Por quê? Uma fusão é uma descontinuidade, traz incógnitas. Como conflitos - o código pode nem criar até que sejam resolvidos. Você precisa executar os testes e confirmar se eles são aprovados para qualquer mesclagem de ramificação. Eu diria mesmo para um avanço rápido, se você quiser jogar pelo seguro. Veja apartsw.com/insights/2016/11/16/…
Dan Cornilescu

Hum, sim, essa garantia é possível, verifique minha resposta. Bem, talvez eu deva esclarecer: por regressão, quero dizer resultados piores que os da linha de base dos ramos (e ignorando a possibilidade de falsos positivos, eles precisam ser abordados, pois podem distorcer a linha de base, descarrilar tudo e exigir intervenção humana). Os falsos negativos intermitentes são apenas um incômodo, retardando as coisas, mas podem ser resolvidos.
precisa

Você não pode garantir nenhuma regressão, apenas garante nenhuma regressão detectada. Se uma mudança causa uma regressão não capturada por um teste, é uma regressão sobre a qual uma ferramenta de IC não pode garantir. E, embora a fusão de dois conjuntos de mudanças traga incógnitas, você pode optar por fazer isso na ramificação do recurso (mesclando a montante) antes de mesclar a outra direção. Se a fonte estiver atualizada com o destino, é uma mesclagem simples (avanço rápido) e, posteriormente, o estado de destino será idêntico ao estado de origem antes da mesclagem; portanto, se os testes forem aprovados antes, serão aprovados depois.
Adrian

Divisão de cabelos. A ferramenta de IC pode ser configurada com um teste para detectar e, assim, proteger contra a regressão com a qual você se preocupa. Não vou discutir muito sobre as fusões - meu objetivo é evitá-los, tanto quanto possível, eles são apenas problemas geral :)
Dan Cornilescu

Meu argumento é que não é a ferramenta de IC que oferece essa proteção, é você escrevendo os testes. A ferramenta de IC não pode fornecer nenhuma garantia além dos testes que você fornece.
Adrian

1

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.


Mas o Reitveld parece ser uma ferramenta colaborativa de revisão de código, não uma ferramenta de IC, estou perdendo alguma coisa? Isto é o que eu olhei: github.com/rietveld-codereview/rietveld
Dan Cornilescu

Zuul parece estar de fato relacionado, estudarei mais de perto.
22617 Dan Cornilescu

Ele não realiza testes, mas lida com alguns aspectos do gerenciamento de filiais, atuando como um sistema de gatekeeper, que é a melhor aposta para impedir que códigos ruins entrem bloqueando a mesclagem.
precisa saber é o seguinte

Eu vejo o que você quer dizer. Bem, ele pode ajudar com a qualidade geral do código, mas por si só não traz nenhuma garantia. Duas mudanças perfeitamente boas que passam todas as verificações de controle de qualidade de forma independente ainda podem causar quebras quando se encontram na ramificação.
Dan Cornilescu 03/03

1

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.


Isso funciona, mas apenas se você não permitir que uma segunda mesclagem inicie as verificações de controle de qualidade antes que a mesclagem anterior seja concluída, caso contrário, a segunda mesclagem não exibirá a primeira, deixando espaço para regressões. Em outras palavras, as mesclagens (incluindo as verificações de controle de qualidade) devem ser completamente serializadas, o que não é dimensionável para equipes grandes.
Dan Cornilescu

0

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.


É bom que você tenha adicionado o aviso, mas pessoalmente considero fazer uma pergunta e responder automaticamente, promovendo sua própria empresa ou produtos como uma forma de spam.
THelper

Eu tenho uma pergunta sobre meta se isso é permitido ou não: meta.devops.stackexchange.com/q/59
THelper

O SnapCI também fez isso. DESCANSE EM PAZ.
paul_h

@paul_h, a menos que esteja faltando algo no SnapCI e seu GoCD de substituição recomendado, ambos são baseados em verificações pós-confirmação (acionadas pela pesquisa no SCM), então eles ainda estão monitorando apenas. Exceto talvez as verificações de relações públicas, mas, a menos que essas verificações sejam completamente serializadas, elas podem apenas reduzir as taxas de ocorrência de regressão, mas não eliminá-las completamente.
22617 Dan Cornilescu

Dan, não votando não, engancha. E um ramo PR viveu de curto que ainda não está incorporada tronco / master - trunkbaseddevelopment.com/game-changers/...
paul_h
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.