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

PDF

Criado por Mike Stephens (AWS), Stephen ( DiCato AWS), Tim Wondergem (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, Gitflow e Flow. GitHub 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 Gitflow 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. O Gitflow é 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 GitHub Flow. 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 do Gitflow. É 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.

• (Opcional) Plugin Gitflow, instalado.

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 ramificação de recursos até a implantação na produção.

Para obter mais informações sobre ambientes e ramificações em uma abordagem do Contas da AWS Gitflow, consulte Escolhendo uma estratégia de ramificação do Git para ambientes com várias contas. 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 as 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.

• (Opcional) O plug-in Gitflow é uma coleção de extensões do Git que fornecem operações de repositório de alto nível para o modelo de ramificação do Gitflow.

Repositório de código

Esse arquivo fonte para o diagrama nesse padrão está disponível na Estratégia de ramificação do GitHub Git para repositório. GitFlow 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 eficácia o desenvolvimento baseado em Gitflow, promover a colaboração, melhorar a qualidade do código e agilizar o processo de desenvolvimento.

Épicos

Analisando os fluxos de trabalho do Gitflow

Tarefa	Descrição	Habilidades necessárias
Revise o processo padrão do Gitflow.	No ambiente sandbox, o desenvolvedor cria uma feature ramificação a partir da ramificação e usa o develop padrão de nomenclatura. feature/<ticket>_<initials>_<short description> O desenvolvedor desenvolve o código e implanta o código no ambiente sandbox de forma iterativa para concluir o tíquete. nota Opcionalmente, o desenvolvedor pode criar uma sandbox ramificação para executar um pipeline automatizado de compilação ou implantação no ambiente sandbox. O desenvolvedor cria uma solicitação de mesclagem da feature ramificação para a develop ramificação usando uma mesclagem de squash. Um pipeline de integração contínua e entrega contínua (CI/CD) cria e implanta automaticamente a develop filial no ambiente de desenvolvimento. (Opcional) Um desenvolvedor integra feature ramificações adicionais à ramificação de desenvolvimento antes de continuar com as atividades de lançamento. Quando você estiver pronto para lançar os recursos na develop ramificação, o desenvolvedor cria uma release ramificação com o nome release/v<number> da develop ramificação. O desenvolvedor cria a ramificação de lançamento, que publica artefatos para reutilização em outros ambientes. 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. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash.	DevOps engenheiro
Revise o processo de hotfix do Gitflow.	O desenvolvedor cria uma hotfix ramificação a partir da main ramificação e usa o padrão hotfix/<ticket>_<initials>_<short description> de nomenclatura. O desenvolvedor cria uma release ramificação a partir da main ramificação e a nomeiarelease/v<number>. O desenvolvedor corrige o problema, confirma a correção e cria a hotfix ramificação. O desenvolvedor cria uma solicitação de mesclagem da hotfix ramificação para a release/v<number> ramificação usando uma mesclagem de squash. O desenvolvedor cria a release filial, que publica artefatos para reutilização em outros ambientes. 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. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. Se um conflito for detectado, os desenvolvedores recebem um alerta e resolvem o conflito com uma solicitação de mesclagem.	DevOps engenheiro
Revise o processo de correção de bugs do Gitflow.	O desenvolvedor cria uma bugfix ramificação a partir da release/v<number> ramificação atual 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 cria uma solicitação de mesclagem da bugfix ramificação para a release/v<number> ramificação usando uma mesclagem de squash. O desenvolvedor cria a release filial, que publica artefatos para reutilização em outros ambientes. 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 Stage. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de produção. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. Se um conflito for detectado, os desenvolvedores recebem um alerta e resolvem o conflito com uma solicitação de mesclagem.	DevOps engenheiro

Analisando os fluxos de trabalho do Gitflow

Tarefa	Descrição	Habilidades necessárias
Revise o processo padrão do Gitflow.	No ambiente sandbox, o desenvolvedor cria uma feature ramificação a partir da ramificação e usa o develop padrão de nomenclatura. feature/<ticket>_<initials>_<short description> O desenvolvedor desenvolve o código e implanta o código no ambiente sandbox de forma iterativa para concluir o tíquete. nota Opcionalmente, o desenvolvedor pode criar uma sandbox ramificação para executar um pipeline automatizado de compilação ou implantação no ambiente sandbox. O desenvolvedor cria uma solicitação de mesclagem da feature ramificação para a develop ramificação usando uma mesclagem de squash. Um pipeline de integração contínua e entrega contínua (CI/CD) cria e implanta automaticamente a develop filial no ambiente de desenvolvimento. (Opcional) Um desenvolvedor integra feature ramificações adicionais à ramificação de desenvolvimento antes de continuar com as atividades de lançamento. Quando você estiver pronto para lançar os recursos na develop ramificação, o desenvolvedor cria uma release ramificação com o nome release/v<number> da develop ramificação. O desenvolvedor cria a ramificação de lançamento, que publica artefatos para reutilização em outros ambientes. 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. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash.	DevOps engenheiro
Revise o processo de hotfix do Gitflow.	O desenvolvedor cria uma hotfix ramificação a partir da main ramificação e usa o padrão hotfix/<ticket>_<initials>_<short description> de nomenclatura. O desenvolvedor cria uma release ramificação a partir da main ramificação e a nomeiarelease/v<number>. O desenvolvedor corrige o problema, confirma a correção e cria a hotfix ramificação. O desenvolvedor cria uma solicitação de mesclagem da hotfix ramificação para a release/v<number> ramificação usando uma mesclagem de squash. O desenvolvedor cria a release filial, que publica artefatos para reutilização em outros ambientes. 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. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. Se um conflito for detectado, os desenvolvedores recebem um alerta e resolvem o conflito com uma solicitação de mesclagem.	DevOps engenheiro
Revise o processo de correção de bugs do Gitflow.	O desenvolvedor cria uma bugfix ramificação a partir da release/v<number> ramificação atual 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 cria uma solicitação de mesclagem da bugfix ramificação para a release/v<number> ramificação usando uma mesclagem de squash. O desenvolvedor cria a release filial, que publica artefatos para reutilização em outros ambientes. 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 Stage. Um aprovador aprova manualmente a implantação dos artefatos de lançamento no ambiente de produção. O desenvolvedor mescla a release ramificação com a main ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. O desenvolvedor mescla a release ramificação com a develop ramificação. Idealmente, o desenvolvedor usa um script automatizado para realizar uma mesclagem rápida. Não use uma mesclagem de squash. Se um conflito for detectado, os desenvolvedores recebem um alerta e resolvem o conflito com uma solicitação de mesclagem.	DevOps engenheiro

Solução de problemas

Problema	Solução
Conflitos filiais	Um problema comum que pode ocorrer com o modelo Gitflow é quando um hotfix precisa ocorrer na produção, mas uma alteração correspondente precisa ocorrer em um ambiente inferior, onde outra ramificação está modificando os mesmos recursos. Recomendamos que você tenha apenas uma única ramificação de lançamento ativa por vez. Se você tiver mais de um ativo por vez, as mudanças nos ambientes podem colidir e talvez você não consiga levar uma filial para a produção.
Mesclar	As versões devem ser incorporadas novamente à principal e desenvolvidas o mais rápido possível para consolidar o trabalho nas ramificações principais.
Fusão de squash	Use uma mesclagem de squash somente quando estiver mesclando de uma feature ramificação para outra. develop Usar mesclagens de abóbora em galhos mais altos causa dificuldade ao mesclar mudanças de volta para galhos mais baixos.

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

Orientação do Gitflow

• O blog original do Gitflow (postagem no blog de Vincent Driessen)

• Fluxo de trabalho do Gitflow (Atlassian)

• Gitflow ativado GitHub: Como usar fluxos de trabalho do Git Flow com GitHub repositórios baseados (vídeo) YouTube

• Exemplo de Git Flow Init (vídeo) YouTube

• A ramificação de lançamento do Gitflow do início ao fim (vídeo) YouTube

Outros recursos

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