As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Benefícios de integridade ambiental de uma abordagem baseada em troncos
Como muitos desenvolvedores sabem, uma mudança no código às vezes pode criar um efeito borboleta
Quando os cientistas conduzem um experimento, eles separam as cobaias em dois grupos: o grupo experimental e o grupo controle. A intenção é tornar o grupo experimental e o grupo controle completamente idênticos, exceto pelo que está sendo testado no experimento. Quando algo acontece no grupo experimental que não acontece no grupo controle, a única causa pode ser a coisa que está sendo testada.
Pense nas mudanças em uma implantação como um grupo experimental e pense em cada ambiente como grupos de controle separados. Os resultados dos testes em um ambiente inferior só são confiáveis quando os controles são iguais aos de um ambiente superior. Quanto mais os ambientes se desviam, maior a chance de descobrir defeitos nos ambientes superiores. Em outras palavras, se as alterações no código falharem na produção, preferimos que elas falhem primeiro na versão beta para que nunca cheguem à produção. É por isso que todos os esforços devem ser feitos para manter cada ambiente, desde o ambiente de teste mais baixo até a própria produção, em sincronia. Isso é chamado de integridade do ambiente.
O objetivo de qualquer processo completo de CI/CD é descobrir problemas o mais cedo possível. Preservar a integridade do ambiente usando uma abordagem baseada em troncos pode praticamente eliminar a necessidade de hotfixes. Em um fluxo de trabalho baseado em troncos, é raro que um problema apareça pela primeira vez no ambiente de produção.
Em uma abordagem Gitflow, depois que um hotfix é implantado diretamente nos ambientes superiores, ele é adicionado à ramificação de desenvolvimento. Isso preserva a correção para futuros lançamentos. No entanto, o hotfix foi desenvolvido e testado diretamente do estado atual do aplicativo. Mesmo que o hotfix funcione perfeitamente na produção, existe a possibilidade de surgirem problemas ao interagir com os recursos mais novos no ramo de desenvolvimento. Como a implantação de um hotfix para um hotfix geralmente não é desejável, isso faz com que os desenvolvedores gastem mais tempo tentando adaptar o hotfix ao ambiente de desenvolvimento. Em muitos casos, isso pode levar a uma dívida técnica significativa e reduzir a estabilidade geral do ambiente de desenvolvimento.
Quando ocorre uma falha em um ambiente, todas as alterações são revertidas para que o ambiente retorne ao estado anterior. Qualquer alteração em uma base de código deve reiniciar o pipeline desde o primeiro estágio. Quando surge um problema no ambiente de produção, a correção também deve passar por todo o pipeline. O tempo extra necessário para percorrer os ambientes mais baixos geralmente é insignificante em comparação com os problemas que são evitados com o uso dessa abordagem. Como todo o propósito dos ambientes inferiores é detectar erros antes que eles cheguem à produção, contornar esses ambientes por meio de uma abordagem Gitflow é um risco ineficiente e desnecessário.
