Explore o modelo de filial Git para entrega contínua

A entrega bem-sucedida de software depende de uma estratégia de ramificação que equilibre velocidade, qualidade e gerenciamento de riscos. O objetivo é enviar melhorias rapidamente, mantendo a estabilidade da produção.

Equilíbrio Estratégico: Velocidade vs. Qualidade

Um modelo de ramificação eficaz deve encontrar o equilíbrio certo:

• Minimize a sobrecarga do processo para acelerar o tempo de entrada no mercado.
• Mantenha portões de qualidade para evitar que os defeitos cheguem à produção.
• Habilite o desenvolvimento paralelo para escalabilidade da equipe.
• Suporte a implantação rápida de hotfix para problemas críticos.

Embora existam inúmeras estratégias de ramificação Git, a abordagem mais eficaz combina padrões comprovados com as necessidades específicas da sua equipe. As equipes corporativas modernas normalmente adotam um modelo de desenvolvimento leve e baseado em tronco, centrado em ramificações de recursos e solicitações pull.

Princípio Fundamental: Sempre Pronto Ramo Principal

Esta unidade ensina a implementar um modelo de ramificação pronto para entrega contínua usando ramificações de funcionalidades e pull requests para manter sempre implantável a ramificação principal.

Estrutura de estratégia de ramificação empresarial

Os seguintes princípios estabelecem uma base sólida para a entrega contínua:

Estabilidade do ramo principal

• Única fonte de verdade: O ramo principal é o caminho exclusivo para lançamentos de produção.
• Prontidão para produção: A ramificação principal deve estar sempre em um estado implantável.
• Proteção de ramificação: implemente políticas abrangentes de ramificação para evitar confirmações diretas.
• Alterações fechadas: Todas as modificações fluem exclusivamente através de solicitações pull.
• Acompanhamento de lançamento: marque todas as versões de produção com tags semânticas do Git.

Disciplina da Ramificação de Funcionalidades

• Desenvolvimento isolado: crie ramificações dedicadas para todos os recursos e correções de bugs.
• Integração de sinalizadores de recursos: gerencie recursos de longa execução com alternâncias de recursos para reduzir a vida útil das ramificações.
• Nomenclatura estratégica: use convenções de nomenclatura descritivas que reflitam o valor comercial.
• Fluxo de trabalho de solicitação pull: mescle para o principal exclusivamente por meio de solicitações pull revisadas.

Estratégia de ramificação de lançamento

• Preparação dedicada: crie ramificações de versão a partir de pontos de integração de funções estáveis.
• Garantia de qualidade: Realizar testes completos e estabilização em ramificações de liberação.
• Fortalecimento de produção: Aplique correções finais de bugs e otimizações de desempenho.
• Rastreamento de marcos: marque marcos de lançamento significativos para rastreabilidade.

Convenções de nomenclatura para escala

# Bug fixes
bugfix/[ticket-id]-description
bugfix/AUTH-123-login-timeout

# Feature development
features/[area]/[feature-name]
features/authentication/oauth-integration
features/api/rate-limiting

# Hotfixes
hotfix/[severity]-description
hotfix/critical-payment-gateway

# Personal branches
users/[username]/[description]
users/john-doe/experimental-caching

Gestão de Pull Request

• Revisão obrigatória do código: Sem exceções para fusões diretas à principal.
• Validação automatizada: integre pipelines de CI/CD para portas de qualidade.
• Métricas de desempenho: acompanhe e otimize o tempo de conclusão da solicitação pull.
• Compartilhamento de conhecimento: use avaliações para aprendizado em equipe e aplicação de padrões.

Pré-requisitos e configuração

Ferramentas essenciais para fluxos de trabalho Git empresariais

Este exercício prático aproveita a abrangente cadeia de ferramentas de DevOps do Azure:

• CLI do Azure: interface de linha de comando nativa da nuvem para serviços do Azure.
• CLI do Azure DevOps: Extensão especializada para integração perfeita de ferramentas Git, CI/CD e Agile no Windows, Linux e macOS.

Configuração da CLI do Azure DevOps

A CLI do Azure DevOps fornece formatação de saída flexível (JSON, YAML, tabela, TSV) para dar suporte a vários cenários de automação. Configure seu formato preferido usando:

az devops configure --defaults output=table

Implementação Prática: Fluxo de Trabalho Git Empresarial

Este passo a passo abrangente demonstra ramificação de nível empresarial no Git para entrega contínua, abrangendo desenvolvimento de funcionalidades, implementação de correções rápidas e resolução de conflitos.

Etapa 1: Criação e desenvolvimento do ramo de funcionalidades

Crie uma ramificação de recurso seguindo as convenções de nomenclatura da empresa:

myWebApp

git checkout -b feature/myFeature-1

Saída:Alternado para uma nova ramificação 'feature/myFeature-1'.

Verifique o contexto da ramificação e o status da árvore de trabalho:

myWebApp

git branch

Saída:✓ feature/myFeature-1

• principal*

Etapa 2: Implementação de recursos e controle de versão

Implemente as alterações de funcionalidades.

myWebApp

# Edit your source files
code Program.cs  # Or your preferred editor

Siga o ciclo de vida completo do commit:

myWebApp

git status

Saída:Recurso de ramificação/myFeature-1Alterações não preparadas para confirmação:

• Modificado: Program.cs*

myWebApp

git add .
git commit -m "feat: implement myFeature-1 with enhanced error handling"

Saída:[feature/myFeature-1 70f67b2] feat: implementar myFeature-1 com tratamento de erros aprimorado1 arquivo alterado, 1 inserção (+)

Publicar no repositório remoto:

myWebApp

git push -u origin feature/myFeature-1

Saída:Para https://dev.azure.com/organization/teamproject/_git/MyWebApp

• [new branch] feature/myFeature-1 -> feature/myFeature-1Branch feature/myFeature-1 configurado para rastrear o recurso de ramificação remota/myFeature-1 desde a origem.

Etapa 3: Configuração da CLI do Azure DevOps e criação de solicitação pull

Configure a CLI do Azure DevOps para sua organização e projeto. Substitua o nome da organização e do projeto:

az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

Crie um novo pull request (usando a CLI do Azure DevOps) para rever as alterações na branch feature-1:

az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

Use a opção --open ao gerar o pull request para abri-lo em um navegador web depois de criado. O --deletesource-branch switch pode ser usado para excluir a ramificação após a conclusão da solicitação pull. Além disso, considere usar --auto-complete para concluir automaticamente quando todas as regras tiverem sido aprovadas e a ramificação de origem puder ser integrada na ramificação de destino.

A equipe analisa conjuntamente as alterações de código e aprova a solicitação pull:

A versão principal está pronta para ser lançada. A equipe marca a ramificação principal com o número da versão:

Etapa 4: Desenvolvimento paralelo de funcionalidades

Comece a trabalhar na Funcionalidade 2. Crie uma ramificação remota da ramificação principal e faça o checkout localmente:

myWebApp

git push origin main:refs/heads/feature/myFeature-2

Output:Total 0 (delta 0), reutilizado 0 (delta 0) Para https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nova ramificação] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Saída:Alterado para um novo ramo 'feature/myFeature-2'. O ramo feature/myFeature-2 foi configurado para rastrear o ramo remoto feature/myFeature-2 a partir da origem.

Modifique Program.cs alterando a mesma linha de comentário no código alterado no recurso-1:

```
public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
```

Etapa 5: Cenário de Pull Request para Recurso 2 e Hotfix

Confirme as alterações localmente, envie-as por push para o repositório remoto e, em seguida, gere uma solicitação pull para mesclar as alterações do recurso/myFeature-2 para a ramificação principal:

az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

Um bug crítico é relatado na produção em relação à versão feature-1 com o pull request em andamento. Para investigar o problema, necessita fazer debugging em relação à versão do código atualmente implementado em produção. Para investigar o problema, crie uma nova ramificação fof usando a tag release_feature1:

myWebApp

git checkout -b fof/bug-1 release_feature1

Saída:Mudou para uma nova ramificação, 'fof/bug-1'.

Etapa 6: Implementação de hotfix crítico

Modifique Program.cs alterando a mesma linha de código que foi alterada na versão feature-1:

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Prepare e confirme as alterações localmente e, em seguida, envie as alterações por push para o repositório remoto:

myWebApp

git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

Saída:Para https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [novo ramo] fof/bug-1 - Ramo fof/bug-1 configurado para rastrear ramo remoto fof/bug-1 de origem.

Etapa 7: Integração de hotfix e resolução de conflitos

Imediatamente após as alterações terem sido implementadas na produção, marque a ramificação fof\bug-1 com a tag release_bug-1 e, em seguida, gere uma solicitação pull para mesclar as alterações de fof/bug-1 de volta à principal:

az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

Como parte da solicitação pull, a ramificação é excluída. No entanto, você ainda pode fazer referência a todo o histórico usando a tag .

Com a correção do bug crítico fora do caminho, vamos rever o pull request da feature-2.

A página de ramificações deixa claro que a ramificação feature/myFeature-2 é uma mudança à frente da principal e duas alterações atrás da principal:

Se você tentasse aprovar a solicitação pull, veria uma mensagem de erro informando sobre um conflito de mesclagem:

Resolver conflitos de fusão

Para resolver conflitos de mesclagem, você pode usar a interface Web do Azure DevOps ou resolvê-los localmente usando comandos Git. Para resolução local, primeiro atualize sua ramificação de recursos com as alterações mais recentes da principal:

```CMD
git checkout feature/myFeature-2
git fetch origin
git merge origin/main
```

Resolva os conflitos no seu editor preferido e, em seguida, conclua a mesclagem:

```CMD
git add .
git commit -m "Resolve merge conflicts between feature-2 and main"
git push origin feature/myFeature-2
```

Com os conflitos resolvidos, a solicitação pull pode ser concluída com êxito.

Neste ponto, você pode criar uma ramificação de versão com base na correção de bug crítico implementada na ramificação fof/bug-1 e mesclada na principal. Usando o comando git checkout, crie uma ramificação de liberação dedicada a partir da ramificação principal.

git checkout -b release/v1.1 main

Este comando cria uma nova ramificação chamada release/v1.1 com base na ramificação principal.

À medida que marcos significativos são alcançados durante o processo de lançamento, etiquete as versões no ramo de lançamento usando tags Git. As tags servem como marcadores para indicar versões específicas do software.

git tag -a v1.1 -m "Release version 1.1"

Este comando cria uma tag chamada v1.1 para marcar a versão de lançamento 1.1 na ramificação de lançamento.

Como funciona

Aprendemos como o modelo de ramificação Git oferece a flexibilidade de trabalhar em recursos em paralelo, criando uma ramificação para cada recurso.

O fluxo de trabalho de solicitação pull permite que você revise as alterações de código usando as políticas de ramificação.

As tags Git são uma ótima maneira de registrar marcos, como a versão do código liberada; oferecem uma maneira de criar ramificações a partir de tags.

Criamos uma ramificação a partir de uma tag de lançamento anterior para corrigir um bug crítico na produção.

A visualização de ramificações no portal da Web facilita a identificação de ramificações antes da principal. Além disso, força um conflito de mesclagem se quaisquer pull requests em andamento tentarem mesclar com o ramo principal sem resolver os conflitos de mesclagem.

Um modelo de ramificação enxuta permite criar ramificações de curta duração e empurrar as mudanças de qualidade para a produção mais rapidamente.