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á.
# Como CI/CD os processos são totalmente diferentes
Os pipelines de CI/CD usam um *fluxo de trabalho moderno baseado em troncos*, no qual os desenvolvedores mesclam atualizações pequenas e frequentes em uma ramificação principal (ou *tronco*) que é criada e testada por meio da parte de CD do pipeline. CI/CD Esse fluxo de trabalho substituiu o *fluxo de trabalho do Gitflow*, em que as ramificações de desenvolvimento e lançamento são separadas por uma programação de lançamento. Em muitas organizações, o Gitflow ainda é um método popular de controle de versão e implantação. No entanto, agora é considerado legado e pode ser difícil integrá-lo a um CI/CD pipeline.
Para muitas organizações, a transição de um fluxo de trabalho do Gitflow para um fluxo de trabalho baseado no trunk foi incompleta, e o resultado é que elas ficam presas em algum lugar ao longo do caminho e nunca migram totalmente para o CI/CD. De alguma forma, seus pipelines acabam mantendo certos resquícios do fluxo de trabalho legado, presos em um estado de transição entre o passado e o presente. Analise as diferenças nos fluxos de trabalho do Git e, em seguida, saiba como o uso de um fluxo de trabalho legado pode afetar o seguinte:
+ [Integridade do ambiente](environment-integrity.md)
+ [Versões](releases.md)
+ [Segurança](security.md)
Para facilitar a identificação dos remanescentes de um fluxo de trabalho legado do Git em uma configuração moderna, vamos comparar o [Gitflow](#gitflow-approach) com a abordagem moderna [baseada no trunk](#trunk-based-approach).
## Abordagem do Gitflow
A imagem a seguir mostra o fluxo de trabalho do Gitflow. A abordagem do Gitflow usa várias ramificações para rastrear várias versões diferentes do código ao mesmo tempo. Você programa lançamentos de atualizações em uma aplicação para algum momento no futuro, enquanto os desenvolvedores ainda trabalham na versão atual do código. Repositórios baseados no trunk podem usar sinalizadores de recursos para fazer isso, mas eles são incorporados ao Gitflow por padrão.
![\[Um fluxo de trabalho do Gitflow com ramificações de recursos, desenvolvimento, lançamento e hotfix\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
Um resultado da abordagem do Gitflow é que os ambientes de aplicações geralmente estão fora de sincronia. Em uma implementação padrão do Gitflow, os ambientes de desenvolvimento refletem o estado atual do código, enquanto os ambientes de pré-produção e produção permanecem congelados no estado da base de código desde a versão mais recente.
Isso complica as coisas quando uma falha aparece no ambiente de produção porque a base de código em que os desenvolvedores trabalham não pode ser mesclada à produção sem expor recursos não lançados. A forma como o Gitflow lida com essa situação é usando um hotfix. Uma ramificação de hotfix é criada da ramificação de lançamento e depois implantada diretamente nos ambientes superiores. A ramificação de hotfix é então mesclada à ramificação de desenvolvimento para manter o código atualizado.
## Abordagem baseada no trunk
A imagem a seguir mostra o fluxo de trabalho baseado no trunk. Em um fluxo de trabalho baseado no trunk, os desenvolvedores criam e testam recursos localmente em uma ramificação de recurso e, em seguida, mesclam essas alterações na ramificação principal. A ramificação principal é então criada para os ambientes de desenvolvimento, pré-produção e produção, sequencialmente. Os testes unitários e de integração ocorrem entre cada ambiente.
![\[Um fluxo de trabalho baseado no trunk com ramificações de recurso e uma ramificação principal.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
Usando esse fluxo de trabalho, todos os ambientes estão operando a mesma base de código. Não há necessidade de uma ramificação de hotfix para os ambientes superiores porque você pode implementar alterações na ramificação principal sem expor recursos não lançados. A ramificação principal é sempre considerada estável, livre de defeitos e pronta para ser liberada. Isso ajuda você a integrá-lo como fonte para um CI/CD pipeline, que pode testar e implantar automaticamente sua base de código em todos os ambientes do pipeline.
# 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](https://www.americanscientist.org/article/understanding-the-butterfly-effect) (artigo da American Scientist), em que um pequeno desvio aparentemente não relacionado desencadeia uma reação em cadeia que causa resultados inesperados. Os desenvolvedores devem então investigar a fundo para descobrir a causa raiz.
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 CI/CD processo completo é descobrir os 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.
# Descobrir os benefícios de uma abordagem baseada no trunk
Uma das coisas que geralmente torna necessário um hotfix é que, em um fluxo de trabalho legado, o estado da aplicação em que os desenvolvedores estão trabalhando pode conter vários recursos não lançados que ainda não estão em produção. O ambiente de produção e o de desenvolvimento só ficam sincronizados quando ocorre um lançamento programado e, em seguida, eles imediatamente começam a divergir novamente até o próximo lançamento programado.
É possível programar lançamentos em um CI/CD processo completo. Você pode atrasar a liberação do código para a produção usando sinalizadores de recursos. No entanto, um CI/CD processo completo permite mais flexibilidade, tornando desnecessários os lançamentos programados. Afinal, *contínuo* é uma palavra-chave em CI/CD, e isso sugere que as mudanças são lançadas à medida que ficam prontas. Evite manter um ambiente de lançamento separado que esteja quase sempre fora de sincronia com os ambientes de teste inferiores.
Se um pipeline de CI/CD não for totalmente otimizado, a divergência entre os ambientes superior e inferior geralmente ocorrerá no nível da ramificação. Os desenvolvedores trabalham em uma ramificação de desenvolvimento e mantêm uma ramificação de lançamento separada, que é atualizada somente quando chega a hora de um lançamento programado. À medida que a ramificação de lançamento e a de desenvolvimento divergem, outras complicações podem surgir.
Além de os ambientes estarem fora de sincronia, à medida que os desenvolvedores trabalham na ramificação de desenvolvimento e se acostumam com um estado da aplicação muito à frente do que está em produção, eles precisam se reajustar ao estado de produção sempre que surge um problema. O estado da ramificação de desenvolvimento pode ter muitos recursos a mais do que o da produção. Quando os desenvolvedores trabalham nessa ramificação todos os dias, é difícil lembrar o que foi ou não liberado para produção. Isso aumenta o risco de que novos bugs sejam introduzidos durante o processo de correção de outros bugs. Esse resultado é um ciclo aparentemente interminável de correções que estendem os prazos e atrasam o lançamento de recursos por semanas, meses ou até anos.
# Benefícios de segurança de uma abordagem baseada no trunk
Um CI/CD processo completo fornece uma abordagem de implantação de fonte única e confiável totalmente automatizada. O pipeline tem um único ponto de entrada. As atualizações de software entram no pipeline no início e são passadas como estão de um ambiente para o outro. Se um problema for descoberto em qualquer etapa do pipeline, as alterações de código que o corrigem deverão passar pelo mesmo processo e começar na primeira etapa. Reduzir os pontos de entrada em um pipeline também reduz as possíveis maneiras pelas quais as vulnerabilidades podem ser introduzidas no pipeline.
Além disso, como o ponto de entrada é o ponto mais distante possível do ambiente de produção, isso reduz de forma significativa a probabilidade de as vulnerabilidades chegarem à produção. Se você implementar um processo de aprovação manual em um pipeline de CI/CD totalmente automatizado, ainda poderá permitir a decisão de aprovação ou rejeição sobre a promoção de alterações para o próximo ambiente. O tomador de decisão não é necessariamente a mesma pessoa que implementa as alterações. Isso separa as responsabilidades de quem implanta as alterações de código e do aprovador dessas alterações. Também torna mais viável que um líder de organização menos técnico desempenhe a função de aprovador.
Por fim, o único ponto de entrada ajuda a limitar o acesso de gravação ao console da interface do usuário (UI) do ambiente de produção a alguns usuários, ou até mesmo a nenhum. Ao reduzir o número de usuários que podem fazer alterações manuais no console, você reduz o risco de eventos de segurança. A capacidade de gerenciar manualmente o console no ambiente de produção é muito mais necessária em fluxos de trabalho legados do que em uma abordagem CI/CD automatizada. Essas alterações manuais são mais difíceis de rastrear, revisar e testar. Elas geralmente são feitas para economizar tempo, mas, no longo prazo, acrescentam uma dívida técnica significativa ao projeto.
Os problemas de segurança do console não são necessariamente causados por agentes mal-intencionados. Muitos dos problemas que ocorrem no console são acidentais. A exposição acidental à segurança é muito comum, o que levou ao surgimento do modelo de segurança de confiança zero. Esse modelo postula, em parte, que acidentes de segurança são menos prováveis quando até mesmo a equipe interna tem o mínimo de acesso possível, também conhecido como permissões de *privilégio mínimo*. Preservar a integridade do ambiente de produção ao restringir todos os processos a um pipeline automatizado praticamente elimina o risco de problemas de segurança relacionados ao console.