Imagine que o time de desenvolvimento precisa lançar uma nova tela de login. O desenvolvedor cria uma branch, faz o código, abre o Pull Request. O servidor de CI roda testes automáticos. Após o Merge na main, a esteira faz o Deploy do artefato em ambiente de Staging. Após a validação do QA, fazemos a Release para os usuários.

Em uma equipe de tecnologia moderna que utiliza metodologia ágil (como Scrum ou Kanban) e práticas de CI/CD (Continuous Integration/Continuous Delivery), o versionamento Git é a espinha dorsal que conecta o código ao produto final.

Para entender como tudo se integra, vamos estruturar o fluxo desde o computador do desenvolvedor até o usuário final.

1. O Fluxo de Trabalho (Branching Strategy) Link para o cabeçalho

A estratégia mais comum hoje é o GitHub Flow ou GitLab Flow, focados em simplicidade e agilidade.

  • main (ou master): É a “fonte da verdade”. O que está aqui deve estar sempre em um estado implantável (pronto para ir ao ar).

  • Feature Branches: Quando um desenvolvedor vai trabalhar em uma nova funcionalidade ou correção, ele cria uma ramificação (branch) a partir da main.

Exemplo: feature/novo-login ou fix/erro-pagamento.

  • Pull Request (PR) / Merge Request: Quando o trabalho na branch termina, o desenvolvedor abre um PR. Isso dispara processos automatizados de CI (Integração Contínua): testes unitários, análise de segurança e verificação de estilo de código. Se tudo passar e o time aprovar, o código é mesclado (merged) na main.

2. Ambientes e Ciclo de Vida Link para o cabeçalho

Para garantir a qualidade, o código passa por diferentes “estágios” ou ambientes antes de chegar ao cliente:

Ambiente Descrição
Local (Dev) O computador do desenvolvedor. Onde o código é escrito e testado inicialmente.
Staging (Homologação) Ambiente espelho da produção. Onde o time de QA (Qualidade) ou o Product Owner valida se a funcionalidade funciona como esperado.
Production (Produção) O ambiente onde o usuário final acessa o sistema. É o destino final.

3. O Passo a Passo do Ciclo Link para o cabeçalho

  1. Desenvolvimento: O dev trabalha na Feature Branch.

  2. Integração (CI): O código é enviado para o repositório, passa por testes automatizados e entra na main.

  3. Build: O sistema gera um “pacote” (ex: uma imagem Docker ou um artefato compilado) pronto para ser executado em servidores.

  4. Release: O processo de preparar esse artefato para ser lançado.

  5. Deploy: O ato técnico de colocar o código no servidor.

4. Release vs. Deploy: Qual a diferença? Link para o cabeçalho

Muitas vezes confundidos, são conceitos distintos:

  • Deploy (Implantação): É um evento técnico. É colocar o código no servidor (mover o artefato para a infraestrutura). Você pode fazer um deploy de algo que o usuário ainda não vê (ex: usando uma “Feature Flag” para esconder a nova função).

  • Release (Liberação): É um evento estratégico/de negócio. É tornar a funcionalidade disponível para o usuário final.

Onde a Release entra? Link para o cabeçalho

A Release é o momento em que o produto evolui de versão. Muitas empresas usam o conceito de Release Candidate (RC) — um artefato que passou por todos os testes e está “candidato” a ir para produção. Quando você faz um Deploy em produção e “liga a chave” para o usuário, você está realizando a Release.

Glossário Rápido Link para o cabeçalho

  • Merge: Ato de juntar o código da sua branch com a main.

  • Pipeline: A sequência automática de passos (Testar -> Construir -> Distribuir).

  • Continuous Delivery: Prática onde seu código está sempre pronto para ser lançado (a qualquer momento, com um clique).

  • Continuous Deployment: Evolução do anterior, onde qualquer alteração aprovada vai automaticamente para produção sem intervenção manual.