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á.

# Implemente uma estratégia GitHub de ramificação do Flow para ambientes com várias contas DevOps
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments"></a>

*Mike Stephens e Abhilash Vinod, Amazon Web Services*

## Resumo
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-summary"></a>

Ao gerenciar um repositório de código-fonte, diferentes estratégias de ramificação influenciam os processos de desenvolvimento e de liberação de software empregados pelas equipes de desenvolvimento. Exemplos de estratégias comuns de ramificação incluem Trunk, GitHub Flow e Gitflow. Essas estratégias usam diferentes ramificações, e as atividades realizadas em cada ambiente são distintas. As organizações que estão implementando DevOps processos se beneficiariam de um guia visual para ajudá-las a entender as diferenças entre essas estratégias de ramificação. A utilização deste material visual na sua organização auxilia as equipes de desenvolvimento a coordenar as atividades e cumprir os padrões organizacionais. Esse padrão fornece esse visual e descreve o processo de implementação de uma estratégia de ramificação do GitHub Flow em sua organização.

Esse padrão faz parte de uma série de documentação sobre como escolher e implementar estratégias de DevOps ramificação para organizações com várias Contas da AWS. Esta série foi criada para ajudar você a aplicar a estratégia correta e as melhores práticas desde o início, a fim de otimizar sua experiência na nuvem. GitHub O fluxo é apenas uma estratégia de ramificação possível que sua organização pode usar. Esta série de documentação também aborda os modelos de ramificação [Trunk](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html) e [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html). Se você ainda não fez isso, recomendamos que você analise [Como escolher uma estratégia de ramificação do Git para DevOps ambientes com várias contas](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) antes de implementar a orientação desse padrão. É importante usar a diligência prévia para escolher a estratégia de ramificação mais adequada para a organização.

Este guia fornece um diagrama que mostra como uma organização pode implementar a estratégia GitHub de fluxo. É recomendável que você revise o [AWS DevOps Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) Guidance para analisar as melhores práticas. Esse padrão inclui tarefas, etapas e restrições recomendadas para cada etapa do DevOps processo.

## Pré-requisitos e limitações
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-prereqs"></a>

**Pré-requisitos **
+ Git, [instalado](https://git-scm.com/downloads). Ele é usado como ferramenta de repositório para o código-fonte.
+ Draw.io, [instalado](https://github.com/jgraph/drawio-desktop/releases). Esta aplicação é usada para visualizar e editar o diagrama.

## Arquitetura
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-architecture"></a>

**Arquitetura de destino**

O diagrama apresentado a seguir pode ser usado de forma semelhante a um [Quadro de Punnett](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia). Você alinha as ramificações no eixo vertical com os AWS ambientes no eixo horizontal para determinar quais ações realizar em cada cenário. Os números representam a sequência das atividades no fluxo de trabalho. Neste exemplo, você acompanha o caminho de uma ramificação `feature` até a implantação em um ambiente de produção.

![\[Quadrado de Punnett das atividades do GitHub Flow em cada filial e ambiente.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/images/pattern-img/780a5bce-3cd2-4092-8537-b7a77c3d6b8d/images/8a2a774a-cd85-466e-838e-a9a1f3b58a63.png)


Para obter mais informações sobre ambientes e ramificações em uma abordagem de GitHub fluxo, consulte [Escolhendo uma estratégia de ramificação do Git para](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach) ambientes com várias contas. Contas da AWS DevOps 

**Automação e escala**

A integração contínua e a entrega contínua (CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CDpipelines) também fornecem governança e barreiras para as equipes de desenvolvimento, impondo consistência, padrões, melhores práticas e níveis mínimos de aceitação para aceitação e implantação de recursos. Para obter mais informações, consulte [Praticando a integração contínua e a entrega contínua em AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html).

AWS oferece um conjunto de serviços para desenvolvedores projetados para ajudá-lo a criar CI/CD pipelines. Por exemplo, [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)é um serviço de entrega contínua totalmente gerenciado que ajuda você a automatizar seus pipelines de lançamento para atualizações rápidas e confiáveis de aplicativos e infraestrutura. [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)compila o código-fonte, executa testes e produz pacotes ready-to-deploy de software. Para obter mais informações, consulte [Ferramentas do desenvolvedor em AWS](https://aws.amazon.com/products/developer-tools/).

## Ferramentas
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-tools"></a>

**AWS serviços e ferramentas**

AWS fornece um conjunto de serviços para desenvolvedores que você pode usar para implementar esse padrão:
+ O [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) é um serviço gerenciado e altamente escalável de repositório de artefatos, que facilita o armazenamento e o compartilhamento de pacotes de software para o desenvolvimento de aplicações.
+ O [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) é um serviço de compilação totalmente gerenciado que permite compilar o código-fonte, realizar testes de unidade e produzir artefatos preparados para a implantação.
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)automatiza implantações no Amazon Elastic Compute Cloud (Amazon EC2) ou em instâncias AWS Lambda , funções ou serviços do Amazon Elastic Container Service (Amazon ECS) no local.
+ O [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) ajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software, além de automatizar as etapas necessárias para a implantação contínua de alterações.

**Outras ferramentas**
+ O [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) é uma aplicação voltada para a criação de fluxogramas e diagramas. O repositório de código contém modelos no formato .drawio para o Draw.io.
+ O [Figma](https://www.figma.com/design-overview/) é uma ferramenta de design on-line voltada para a colaboração. O repositório de código contém modelos no formato .fig para o Figma.

**Repositório de código**

Esse arquivo fonte para o diagrama nesse padrão está disponível no repositório GitHub [Git Branching Strategy for GitHub ](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow) Flow. Estão incluídos arquivos nos formatos PNG, draw.io e Figma. É possível modificar esses diagramas para adequação aos processos da sua organização.

## Práticas recomendadas
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-best-practices"></a>

Siga as melhores práticas e recomendações em [AWS DevOps Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html) Guidance e Choosing a [Git branching](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/) strategy para ambientes com várias contas. DevOps Isso ajuda você a implementar com eficiência o desenvolvimento GitHub baseado em Flow, promover a colaboração, melhorar a qualidade do código e simplificar o processo de desenvolvimento.

## Épicos
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-epics"></a>

### Analisando os fluxos de trabalho do GitHub Flow
<a name="reviewing-the-github-flow-workflows"></a>


| Tarefa | Description | Habilidades necessárias | 
| --- | --- | --- | 
| Revise o processo GitHub de fluxo padrão. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps engenheiro | 
| Revise o processo de correção de bugs do GitHub Flow. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps engenheiro | 
| Revise o processo de hotfix GitHub Flow. | GitHub O Flow foi projetado para permitir a entrega contínua, em que as alterações de código são implantadas com frequência e confiabilidade em ambientes superiores. O ponto principal é que cada ramificação `feature` pode ser implantada a qualquer momento.As ramificações `Hotfix`, que são semelhantes às ramificações `feature` ou `bugfix`, podem seguir o mesmo procedimento que qualquer uma dessas outras ramificações. No entanto, devido à sua urgência, as correções urgentes geralmente recebem maior prioridade. Dependendo das políticas da equipe e da urgência da situação, determinadas etapas do processo podem ser agilizadas. Por exemplo, as revisões de código para correções urgentes podem receber prioridade e ser concluídas rapidamente. Assim, embora o processo de correção urgente ocorra de forma semelhante ao processo destinado aos recursos ou às correções de bugs, a urgência envolvida pode justificar adaptações no cumprimento dos procedimentos. É fundamental estabelecer diretrizes sobre o gerenciamento de correções urgentes para garantir que elas sejam tratadas com eficiência e segurança. | DevOps engenheiro | 

## Solução de problemas
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-troubleshooting"></a>


| Problema | Solução | 
| --- | --- | 
| Conflitos em ramificações | Um problema comum que pode ocorrer com o modelo GitHub Flow é quando um hotfix precisa ocorrer na produção, mas uma alteração correspondente precisa ocorrer em uma `feature` `hotfix` ramificação ou ramificação em que os mesmos recursos estão sendo modificados. `bugfix` Recomendamos que você faça a mesclagem das alterações da ramificação `main` para as ramificações menos avançadas com frequência, a fim de evitar conflitos significativos ao mesclar de volta para a ramificação `main`. | 
| Nível de maturidade da equipe | GitHub O Flow incentiva implantações diárias em ambientes superiores, adotando a verdadeira integração contínua e entrega contínua (CI/CD). É indispensável que a equipe conte com maturidade técnica suficiente para desenvolver recursos e criar testes de automação para eles. A equipe precisa conduzir uma análise detalhada da solicitação de mesclagem antes que as alterações sejam aprovadas. Isso promove uma cultura técnica voltada à engenharia, que é robusta e valoriza a qualidade, a responsabilidade e a eficiência no processo de desenvolvimento. | 

## Recursos relacionados
<a name="implement-a-github-flow-branching-strategy-for-multi-account-devops-environments-resources"></a>

Este guia não inclui treinamento em Git. No entanto, existem muitos recursos de alta qualidade disponíveis na internet, caso você precise realizar esse treinamento. Recomendamos que você comece pelo site de [documentação do Git](https://git-scm.com/doc).

Os recursos a seguir podem ajudá-lo em sua jornada de ramificação do GitHub Flow no Nuvem AWS.

**AWS DevOps orientação**
+ [AWS DevOps Orientação](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS Arquitetura de referência do pipeline de implantação](https://pipelines.devops.aws.dev/)
+ [O que DevOps é](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps recursos](https://aws.amazon.com/devops/resources/)

**GitHub Orientação de fluxo**
+ [GitHub Tutorial de início rápido do Flow](https://docs.github.com/en/get-started/using-github/github-flow) () GitHub
+ [Por que GitHub Flow?](https://githubflow.github.io/)

**Outros recursos**
+ [Twelve-factor app methodology](https://12factor.net/) (12factor.net)