Como as alterações pré-verificadas com sucesso causam regressões que deveriam ter sido capturadas?

Em um contexto de IC, uma das medidas comumente usadas para aumentar os níveis de qualidade da ramificação de integração é um conjunto obrigatório de verificações de qualidade de pré-confirmação (geralmente incluindo a construção de alguns artefatos, a execução de testes de unidade e até alguns testes de recursos / integração).

No entanto, algumas regressões (quebras de construção, várias falhas de teste) são detectadas pelas verificações do sistema de IC exatamente nas áreas que deveriam ser cobertas por essas verificações obrigatórias de pré-confirmação.

Durante a análise dessas regressões, um argumento frequentemente ouvido é que o desenvolvedor que cometeu a alteração identificada como causa raiz da regressão passou com êxito em todas essas verificações. E muitas vezes a alegação é apoiada por evidências concretas que indicam que:

• após a versão final da mudança, ela foi transportada para um novo espaço de trabalho com base na ponta da ramificação
• os artefatos necessários foram construídos a partir do zero (portanto, a construção foi totalmente correta, sem problemas relacionados ao cache etc.)
• todos os testes obrigatórios passaram, incluindo aqueles que cobrem a área em questão e deveriam ter detectado a regressão
• nenhum falso positivo intermitente afetou as respectivas verificações
• nenhum arquivo mesclado foi detectado ao confirmar a alteração na ramificação
• nenhum dos arquivos que estão sendo modificados foi tocado por qualquer outra alteração confirmada na ramificação desde que o novo espaço de trabalho foi puxado

É realmente possível que uma alteração de software cause tal regressão, apesar de seguir corretamente todos os processos e práticas prescritos? Quão?

Há uma possibilidade em que posso pensar, se quando o desenvolvedor estiver trabalhando em sua própria estação de trabalho, com algumas vezes imagens criadas para a caixa virtual rodar em sua estação de trabalho em que sua infraestrutura não usa exatamente a mesma imagem.

O desenvolvedor precisará, ao desenvolver um recurso, adicionar um parâmetro da JVM ou qualquer alteração ao middleware no início de seu trabalho e esquecê-lo.

Antes de confirmar, todos os testes de unidade / integração executados em sua estação de trabalho funcionam muito bem, pois a imagem inicial é compartilhada e funciona em todos os sistemas desenvolvidos.

Mas, ao passar pelo IC, ele falha porque a alteração no middleware não foi implementada, porque o desenvolvedor esqueceu de solicitá-lo ou apenas porque a equipe encarregada de atualizar as imagens básicas / sistema de provisionamento não teve o tempo ou se esqueceu de atualizar o sistema.

É bom que ele interrompa o IC, porque informa antes do início da produção que o sistema não funcionará conforme o esperado, mas às vezes se torna um inferno encontrar o parâmetro ausente.

Esse último argumento defende que você rejeite as confirmações e apenas interrompa o IC em um ramo de recursos, para que não bloqueie mais ninguém e deixe que o desenvolvedor resolva o problema mais cedo, quando a mudança for necessária e evite que essa alteração seja esquecida. o fluxo.

FWIW, fizemos exatamente isso aqui, os desenvolvedores tiveram acesso total às máquinas de desenvolvimento e os lançamentos na Q / A falharam porque uma alteração de parâmetro foi esquecida, mudamos para o chef para lidar com a configuração do middleware (tomcat agora), para que cada um fosse necessário a mudança na infraestrutura deve ser codificada em algum lugar e será reproduzida em todos os ambientes.

Claro que é. A produção é sempre diferente. Dinheiro real. Carga real. Usuários reais. Dor de verdade. É por isso que é tão importante colocar qualquer alteração significativa atrás de um sinalizador de recurso. Sua implantação não deve mudar nada. A ativação de um recurso é a única coisa que deve fazer alterações significativas no seu site.

A quebra é sempre teoricamente possível porque a verificação de pré-confirmação executada pelo desenvolvedor é feita isoladamente e, portanto, não pode levar em consideração outras alterações em andamento que estão sendo verificadas em paralelo. Tais mudanças podem interferir umas nas outras e causar regressões sem realmente ter colisões detectáveis ​​no nível do SCM.

Um exemplo simples dessas mudanças interferentes:

Vamos supor que o código na versão mais recente de uma ramificação do projeto inclua uma determinada função, definida em um arquivo e invocada em alguns outros arquivos. Dois desenvolvedores trabalhando em paralelo nesse projeto estão se preparando para fazer algumas alterações no código.

Desenvolvedor A retrabalha essa função removendo ou adicionando um argumento de função obrigatório e, é claro, atualiza todas as chamadas da função em todos os arquivos associados para corresponder à definição atualizada.

O desenvolvedor B decide adicionar uma invocação da referida função em um arquivo que não continha essa invocação antes e, portanto, não é tocado pelas alterações do desenvolvedor A. É claro que o desenvolvedor B está preenchendo a lista de argumentos para corresponder à definição da função visível no rótulo mais recente. Qual é a definição antiga, pois as alterações do desenvolvedor A ainda não foram confirmadas.

Ambos os desenvolvedores executam corretamente as verificações de pré-confirmação com um resultado de aprovação e continuam a confirmar suas alterações de código. Como os dois conjuntos de alterações não tocam os mesmos arquivos, nenhuma mesclagem final acontece, o que normalmente seria uma indicação de problemas em potencial, garantindo uma análise mais detalhada e talvez uma reexecução da verificação pré-confirmação. Nada pode dar uma dica sutil de que algo pode dar errado.

No entanto, o resultado final é catastrófico - a compilação é interrompida, pois a chamada de função adicionada pelo desenvolvedor B não corresponde à definição de função atualizada pelo desenvolvedor A.

Ao encontrar esse tipo de problema, você deve escrever alguns novos testes de aceitação de execução extremamente rápidos que possam resolver esses problemas e adicioná-los aos testes de verificação de compilação que são executados antes dos testes de integração. Você deve estar constantemente mudando para a esquerda e tentando reduzir o ciclo de feedback para os desenvolvedores que efetuam alterações. Se você não conseguir encontrar uma maneira de fazer isso, talvez sua arquitetura não seja tão ágil quanto precisa.

@ Dan Cornilescu - seu cenário é válido para arquiteturas fortemente acopladas, e é por isso que arquiteturas pouco acopladas (microsserviços de APIs RESTful com versão) emergiram como a melhor prática atual em organizações de alto desempenho. Essas organizações de matriz de serviços têm outras complexidades a serem superadas.

Às vezes, é necessário refatorar toda a arquitetura para superar problemas como esses. Acredito que foram o Google e o eBay que redirecionaram completamente suas plataformas 5 vezes (em um período de aproximadamente 10 anos) devido a restrições impostas por sua arquitetura anterior.