Implemente uma estratégia GitHub de ramificação do Flow para ambientes com várias contas DevOps - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosSolução de problemasRecursos relacionados

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

Mike Stephens e Abhilash Vinod, Amazon Web Services

Resumo

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 e Gitflow. 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 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 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

Pré-requisitos

  • Git, instalado. Ele é usado como ferramenta de repositório para o código-fonte.

  • Draw.io, instalado. Esta aplicação é usada para visualizar e editar o diagrama.

Arquitetura

Arquitetura de destino

O diagrama apresentado a seguir pode ser usado de forma semelhante a um Quadro de Punnett (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.

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

AWS oferece um conjunto de serviços para desenvolvedores projetados para ajudá-lo a criar CI/CD pipelines. Por exemplo, AWS CodePipelineé 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 CodeBuildcompila 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.

Ferramentas

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 é 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 é 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 CodeDeployautomatiza 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 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 é 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 é 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 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

Siga as melhores práticas e recomendações em AWS DevOps Well-Architected Guidance e Choosing a Git branching 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

TarefaDescriptionHabilidades necessárias

Revise o processo GitHub de fluxo padrão.

  1. No ambiente de sandbox, o desenvolvedor cria uma ramificação feature com base na ramificação main e usa o padrão de nomenclatura feature/<ticket>_<initials>_<short description>.

  2. O desenvolvedor adiciona uma ou mais confirmações à ramificação feature, cada uma representando uma alteração ou melhoria específica.

  3. O desenvolvedor abre uma solicitação de mesclagem (MR, na sigla em inglês) para mesclar as alterações na ramificação main. Com isso, é iniciado o processo de análise.

  4. Durante o processo de análise, os desenvolvedores debatem as alterações no código e fornecem feedback. A meta é assegurar que as alterações sejam de alta qualidade e estejam em conformidade com os padrões do projeto.

  5. Após o desenvolvedor criar a solicitação de mesclagem, um processo de compilação automatizado é iniciado e implanta as alterações na ramificação feature, localizada no ambiente de desenvolvimento.

  6. Os testes automatizados verificam a integridade e a qualidade das alterações encapsuladas na solicitação de mesclagem. Para que a solicitação de mesclagem seja concluída, é necessário que a compilação, a implantação e os testes tenham êxito.

  7. Quando o processo de análise é concluído, as alterações são mescladas na ramificação main.

  8. Um aprovador autoriza manualmente a implantação dos artefatos da liberação no ambiente de testes.

  9. Um aprovador autoriza manualmente a implantação dos artefatos da liberação no ambiente de preparação.

  10. Um aprovador autoriza manualmente a implantação dos artefatos da liberação no ambiente de produção.

DevOps engenheiro

Revise o processo de correção de bugs do GitHub Flow.

  1. O desenvolvedor cria uma ramificação bugfix com base na ramificação main e usa o padrão de nomenclatura bugfix/<ticket number>_<developer initials>_<descriptor>.

  2. O desenvolvedor corrige o problema, realiza a confirmação da correção e desenvolve a ramificação bugfix.

  3. O desenvolvedor abre uma solicitação de mesclagem para mesclar a ramificação bugfix na ramificação main. Com isso, é iniciado o processo de análise.

  4. Durante o processo de análise, os desenvolvedores debatem as alterações no código e fornecem feedback.

  5. Após a conclusão da análise e da aprovação, o desenvolvedor conclui a solicitação de mesclagem da ramificação bugfix na ramificação main.

  6. Um aprovador autoriza manualmente a implantação dos artefatos da liberação em ambientes mais avançados.

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

ProblemaSoluçã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

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.

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

AWS DevOps orientação

GitHub Orientação de fluxo

Outros recursos