Explorar o modelo GIT branch para entrega contínua

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

Equilíbrio Estratégico: Velocidade versus Qualidade

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

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

Embora existam várias estratégias de ramificação do Git, a abordagem mais eficaz combina padrões comprovados com as necessidades específicas da sua equipe. As equipes empresariais modernas normalmente adotam um modelo de desenvolvimento leve baseado em tronco centrado em ramificações de funcionalidade e pull requests.

Princípio Fundamental: Ramo Principal Sempre Pronto

Esta unidade ensina você a implementar um modelo de branch pronto para entrega contínua usando branches de recursos e solicitações de pull para manter uma ramificação principal consistentemente implantável.

Estrutura Estratégica de Ramificação Empresarial

Os seguintes princípios estabelecem uma base robusta para entrega contínua:

Estabilidade do Ramo Principal

• Fonte única de verdade: a ramificação principal é o caminho exclusivo para versões de produção.
• Preparação de produção: a ramificação principal deve estar sempre em um estado implantável.
• Proteção de branch: implemente políticas de branch abrangentes para evitar confirmações diretas.
• Alterações controladas: todas as modificações fluem exclusivamente por meio de pull requests.
• Rastreamento de lançamentos: Etiquete todas as versões de produção com tags Git semânticas.

Disciplina do Branch de Recursos

• Desenvolvimento isolado: crie branches dedicados para todas as funcionalidades e correções de bugs.
• Integração do sinalizador de recursos: gerencie recursos de execução longa com alternâncias de recursos para reduzir o tempo de vida do branch.
• Nomenclatura estratégica: use convenções de nomenclatura descritivas que reflitam o valor dos negócios.
• Fluxo de trabalho de solicitação de pull: integrar à principal exclusivamente por meio de solicitações de pull revisadas.

Estratégia do Branch de Lançamento

• Preparação dedicada: crie ramificações de lançamento a partir de pontos estáveis de integração de funcionalidades.
• Garantia de qualidade: realize testes abrangentes e estabilização em ramificações de lançamento.
• Endurecimento de produção: Aplicar correções de bugs finais e otimizações de desempenho.
• Acompanhamento 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

Gerenciamento de Pull Requests

• Revisão de código obrigatória: não há exceções para mesclagens diretas à principal.
• Validação automatizada: integrar pipelines de CI/CD para portões de qualidade.
• Métricas de desempenho: acompanhe e otimize o tempo de conclusão da solicitação de pull.
• Compartilhamento de conhecimento: use revisões para o aprendizado de equipe e a imposição de padrões.

Pré-requisitos e instalação

Ferramentas essenciais para fluxos de trabalho git corporativos

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

• CLI do Azure: interface de linha de comando nativa de nuvem para serviços do Azure.
• CLI do Azure DevOps: extensão especializada para integração direta 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 preferencial usando:

az devops configure --defaults output=table

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

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

Etapa 1: Criação e desenvolvimento do feature branch

Crie um ramo de funcionalidades seguindo as convenções de nomenclatura corporativa.

myWebApp

git checkout -b feature/myFeature-1

Saída:Alternado para um novo branch "feature/myFeature-1".

Verificar o contexto do branch 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 alterações na sua funcionalidade.

myWebApp

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

Siga o ciclo completo do commit:

myWebApp

git status

Saída:No branch feature/myFeature-1Alterações não preparadas para commit:

• 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 erro 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

• [novo branch] feature/myFeature-1 -> feature/myFeature-1Branch feature/myFeature-1 configurado para acompanhar o recurso de branch remoto/myFeature-1 de origem.

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

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

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

Crie uma solicitação de pull (usando a CLI do Azure DevOps) para revisar as alterações no 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 elevar a solicitação de pull para abri-la em um navegador da Web depois que ela tiver sido criada. A --deletesource-branch opção pode ser usada para excluir o branch após a conclusão da solicitação de pull. Além disso, considere usar --auto-complete para ser concluído automaticamente quando todas as políticas tiverem passado e o branch de origem puder ser mesclado no branch de destino.

A equipe revisa as alterações de código e aprova a solicitação de pull em conjunto:

O principal está pronto para lançamento. A equipe marca a ramificação principal com o número da versão:

Etapa 4: Desenvolvimento de recursos paralelos

Inicie o trabalho no Recurso 2. Crie um branch no remoto do branch principal e faça o check-out localmente:

myWebApp

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

Saída:Total 0 (delta 0), reutilizado 0 (delta 0) Para https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [novo branch] origem/HEAD -> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Saída:Alternado para um novo recurso de branch "feature/myFeature-2" Branch/myFeature-2 configurado para acompanhar o recurso de branch remoto/myFeature-2 de origem.

Modifique Program.cs alterando a mesma linha de comentário no código alterada no feature-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: Recurso 2 Pull Request e Cenário de Hotfix

Confirme as alterações localmente, envie-as por push para o repositório remoto e gere uma solicitação de pull para mesclar as alterações de feature/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 em produção na versão feature-1 com a solicitação de pull em andamento. Para investigar o problema, você precisa depurar a versão do código implantada em produção no momento. Para investigar o problema, crie uma ramificação fof usando a marca release_feature1:

myWebApp

git checkout -b fof/bug-1 release_feature1

Saída:Alternado para um novo branch, "fof/bug-1".

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

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 as alterações e faça commit delas localmente. Depois 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 branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 configurado para rastrear o fof/bug-1 do branch remoto da origem.

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

Imediatamente depois que as alterações forem distribuídas para produção, marque a ramificação fof\bug-1 com a marca release_bug-1 e crie uma solicitação de pull para mesclar as alterações de fof/bug-1 novamente no 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 de pull, o branch é excluído. No entanto, você ainda pode fazer referência a todo o histórico usando a marcação.

Com a correção do bug crítico feita, vamos revisar a solicitação pull do recurso 2.

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

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

Resolver conflitos de mesclagem

Para resolver conflitos de mesclagem, você pode usar a interface da Web do Azure DevOps ou resolvê-los localmente usando comandos Git. Para resolução local, primeiro atualize seu branch 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 em seu editor preferencial e 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 de pull pode ser concluída com êxito.

Neste ponto, você pode criar um branch de versão com base na correção de bugs crítica implementada no branch fof/bug-1 e mesclada na principal. Usando o comando git checkout, crie um ramo de release dedicado a partir do ramo principal.

git checkout -b release/v1.1 main

Esse comando cria um novo branch chamado release/v1.1 com base no branch principal.

Conforme marcos significativos são alcançados durante o processo de lançamento, marque os lançamentos no branch de lançamento usando tags do Git. As tags servem como marcadores para denotar versões específicas do software.

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

Esse comando cria uma tag chamada v1.1 para marcar a versão de lançamento 1.1 no branch de lançamento.

Como funciona

Aprendemos como o modelo de ramificação do Git oferece a flexibilidade para trabalhar nos recursos em paralelo criando um branch para cada recurso.

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

As tags do Git são uma ótima maneira de registrar marcos, como a versão do código liberada. É possível criar branches usando tags.

Criamos um branch de uma tag de versão anterior para corrigir um bug crítico na produção.

A exibição de branches no portal da Web facilita a identificação dos branches à frente do principal. Além disso, ela força um conflito de mesclagem quando alguma solicitação de pull contínua tenta fazer a mesclagem no principal sem resolver os conflitos de mesclagem.

Um modelo simples permite criar ramificações de curta duração e enviar alterações de qualidade para a produção mais rapidamente.