Implemente uma estratégia GitHub de ramificação do Flow para ambientes com várias contas DevOps

PDF

Criado por Mike Stephens (AWS) e Abhilash Vinod (AWS)

Resumo

Ao gerenciar um repositório de código-fonte, diferentes estratégias de ramificação afetam os processos de desenvolvimento e lançamento de software que as equipes de desenvolvimento usam. Exemplos de estratégias comuns de ramificação incluem Trunk, GitHub Flow e Gitflow. Essas estratégias usam ramificações diferentes e as atividades realizadas em cada ambiente são diferentes. 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. Usar esse visual em sua organização ajuda as equipes de desenvolvimento a alinhar seu trabalho e seguir 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. Use a devida diligência para escolher a estratégia de ramificação certa para sua 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. Isso é usado como uma ferramenta de repositório de código-fonte.

• Draw.io, instalado. Esse aplicativo é usado para visualizar e editar o diagrama.

Arquitetura

Arquitetura de destino

O diagrama a seguir pode ser usado como um quadrado 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 indicam a sequência das ações no fluxo de trabalho. Este exemplo leva você de uma feature filial até a implantação na produção.

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 pipelines de CI/CD. 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:

• AWS CodeArtifacté um serviço de repositório de artefatos gerenciado e altamente escalável que ajuda você a armazenar e compartilhar pacotes de software para desenvolvimento de aplicativos.

• AWS CodeBuildé um serviço de compilação totalmente gerenciado que ajuda você a compilar o código-fonte, executar testes de unidade e produzir artefatos prontos para 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.

• AWS CodePipelineajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software e automatizar as etapas necessárias para liberar alterações de software continuamente.

Outras ferramentas

• O Draw.io Desktop é um aplicativo para criar fluxogramas e diagramas. O repositório de código contém modelos no formato.drawio para Draw.io.

• Figma é uma ferramenta de design on-line projetada para colaboração. O repositório de código contém modelos no formato.fig para 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. Ele inclui arquivos nos formatos PNG, draw.io e Figma. Você pode modificar esses diagramas para apoiar os 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

Analisando os fluxos de trabalho do GitHub Flow

Tarefa	Descrição	Habilidades necessárias
Revise o processo GitHub de fluxo padrão.	No ambiente sandbox, o desenvolvedor cria uma feature ramificação a partir da ramificação e usa o main padrão de nomenclatura. feature/<ticket>_<initials>_<short description> O desenvolvedor adiciona um ou mais commits à feature ramificação, cada um representando uma alteração ou melhoria discreta. O desenvolvedor abre uma solicitação de mesclagem (MR) para mesclar as alterações na main ramificação. Isso inicia um processo de revisão. Durante o processo de revisão, os desenvolvedores discutem as mudanças no código e fornecem feedback. O objetivo é garantir que as mudanças sejam de alta qualidade e atendam aos padrões do projeto. Depois que o desenvolvedor cria a solicitação de mesclagem, um processo de criação automatizado é iniciado e implanta as alterações na feature ramificação no ambiente de desenvolvimento. Testes automatizados verificam a integridade e a qualidade das alterações encapsuladas na solicitação de mesclagem. Uma construção bem-sucedida, uma implantação bem-sucedida e um teste bem-sucedidos são necessários para concluir a solicitação de mesclagem. Quando o processo de revisão estiver concluído, as alterações serão mescladas na main ramificação. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de teste. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de teste. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de produção.	DevOps engenheiro
Revise o processo de correção de bugs do GitHub Flow.	O desenvolvedor cria uma bugfix ramificação a partir da main ramificação e usa o padrão bugfix/<ticket number>_<developer initials>_<descriptor> de nomenclatura. O desenvolvedor corrige o problema, confirma a correção e cria a bugfix ramificação. O desenvolvedor abre uma solicitação de mesclagem para mesclar a bugfix ramificação na main ramificação. Isso inicia um processo de revisão. Durante o processo de revisão, os desenvolvedores discutem as mudanças no código e fornecem feedback. Após a conclusão e aprovação da revisão, o desenvolvedor conclui a solicitação de mesclagem da bugfix filial na main filial. Um aprovador aprova manualmente a implantação dos artefatos de lançamento em ambientes superiores.	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. A chave é que cada feature filial possa ser implantada a qualquer momento. Hotfixramificações, que são semelhantes a feature ou bugfix ramificações, podem seguir o mesmo processo de qualquer uma dessas outras ramificações. No entanto, devido à sua urgência, os hotfixes geralmente têm uma prioridade mais alta. Dependendo das políticas da equipe e da rapidez da situação, certas etapas do processo podem ser aceleradas. Por exemplo, as revisões de código para hotfixes podem ser aceleradas. Portanto, embora o processo de hotfix seja paralelo ao processo de recurso ou correção de bugs, a urgência em torno dos hotfixes pode justificar modificações na adesão aos procedimentos. É fundamental estabelecer diretrizes sobre o gerenciamento de hotfixes para garantir que eles sejam tratados com eficiência e segurança.	DevOps engenheiro

Analisando os fluxos de trabalho do GitHub Flow

Tarefa	Descrição	Habilidades necessárias
Revise o processo GitHub de fluxo padrão.	No ambiente sandbox, o desenvolvedor cria uma feature ramificação a partir da ramificação e usa o main padrão de nomenclatura. feature/<ticket>_<initials>_<short description> O desenvolvedor adiciona um ou mais commits à feature ramificação, cada um representando uma alteração ou melhoria discreta. O desenvolvedor abre uma solicitação de mesclagem (MR) para mesclar as alterações na main ramificação. Isso inicia um processo de revisão. Durante o processo de revisão, os desenvolvedores discutem as mudanças no código e fornecem feedback. O objetivo é garantir que as mudanças sejam de alta qualidade e atendam aos padrões do projeto. Depois que o desenvolvedor cria a solicitação de mesclagem, um processo de criação automatizado é iniciado e implanta as alterações na feature ramificação no ambiente de desenvolvimento. Testes automatizados verificam a integridade e a qualidade das alterações encapsuladas na solicitação de mesclagem. Uma construção bem-sucedida, uma implantação bem-sucedida e um teste bem-sucedidos são necessários para concluir a solicitação de mesclagem. Quando o processo de revisão estiver concluído, as alterações serão mescladas na main ramificação. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de teste. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de teste. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de produção.	DevOps engenheiro
Revise o processo de correção de bugs do GitHub Flow.	O desenvolvedor cria uma bugfix ramificação a partir da main ramificação e usa o padrão bugfix/<ticket number>_<developer initials>_<descriptor> de nomenclatura. O desenvolvedor corrige o problema, confirma a correção e cria a bugfix ramificação. O desenvolvedor abre uma solicitação de mesclagem para mesclar a bugfix ramificação na main ramificação. Isso inicia um processo de revisão. Durante o processo de revisão, os desenvolvedores discutem as mudanças no código e fornecem feedback. Após a conclusão e aprovação da revisão, o desenvolvedor conclui a solicitação de mesclagem da bugfix filial na main filial. Um aprovador aprova manualmente a implantação dos artefatos de lançamento em ambientes superiores.	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. A chave é que cada feature filial possa ser implantada a qualquer momento. Hotfixramificações, que são semelhantes a feature ou bugfix ramificações, podem seguir o mesmo processo de qualquer uma dessas outras ramificações. No entanto, devido à sua urgência, os hotfixes geralmente têm uma prioridade mais alta. Dependendo das políticas da equipe e da rapidez da situação, certas etapas do processo podem ser aceleradas. Por exemplo, as revisões de código para hotfixes podem ser aceleradas. Portanto, embora o processo de hotfix seja paralelo ao processo de recurso ou correção de bugs, a urgência em torno dos hotfixes pode justificar modificações na adesão aos procedimentos. É fundamental estabelecer diretrizes sobre o gerenciamento de hotfixes para garantir que eles sejam tratados com eficiência e segurança.	DevOps engenheiro

Solução de problemas

Problema	Solução
Conflitos filiais	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ê mescle frequentemente as alterações das main ramificações inferiores para evitar conflitos significativos ao mesclar com. main
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). É fundamental que a equipe tenha a maturidade de engenharia para criar recursos e criar testes de automação para eles. A equipe deve realizar uma análise exaustiva da solicitação de mesclagem antes que as alterações sejam aprovadas. Isso promove uma cultura de engenharia robusta que promove qualidade, responsabilidade e eficiência no processo de desenvolvimento.

Recursos relacionados

Este guia não inclui treinamento para Git; no entanto, há muitos recursos de alta qualidade disponíveis na Internet se você precisar desse treinamento. Recomendamos que você comece com o 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

• AWS DevOps Orientação

• AWS Arquitetura de referência do pipeline de implantação

• O que DevOps é

• DevOps recursos

GitHub Orientação de fluxo

• GitHub Tutorial de início rápido do Flow () GitHub

• Por que GitHub Flow?

Outros recursos

• Metodologia de aplicativo de doze fatores (12factor.net)