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á.
Vantagens da integridade ambiental de uma abordagem baseada no trunk
Como muitos desenvolvedores sabem, uma alteração no código às vezes pode criar um efeito borboleta
Quando os cientistas realizam um experimento, eles separam os participantes em dois grupos: o grupo experimental e o grupo de controle. A intenção é tornar o grupo experimental e o grupo de controle completamente idênticos, exceto pelo que está sendo testado no experimento. Quando algo acontece no grupo experimental que não acontece no grupo de controle, a única causa pode ser o que está sendo testado.
Considere as alterações em uma implantação como um grupo experimental, e considere 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 probabilidade de descobrir falhas nos ambientes superiores. Em outras palavras, se as alterações no código forem falhar 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 envidados para manter cada ambiente, desde o ambiente de teste inicial até a própria produção, em sincronia. Isso é denominado integridade do ambiente.
O objetivo de qualquer processo de CI/CD totalmente otimizado é descobrir problemas o mais cedo possível. Preservar a integridade do ambiente usando uma abordagem baseada no trunk pode praticamente eliminar a necessidade de hotfixes. Em um fluxo de trabalho baseado no trunk, é raro que um problema apareça pela primeira vez no ambiente de produção.
Em uma abordagem do 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 da aplicação. Mesmo que o hotfix funcione perfeitamente na produção, existe a possibilidade de surgirem problemas ao interagir com os recursos mais novos na ramificação de desenvolvimento. Como a a implantação de um hotfix para um hotfix normalmente não é desejável, isso faz com que os desenvolvedores gastem mais tempo tentando adequar 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 a primeira etapa. 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 o propósito principal dos ambientes inferiores é detectar erros antes que eles cheguem à produção, ignorá-los por meio de uma abordagem do Gitflow é um risco ineficiente e desnecessário.
