CD - Implantação em Staging

Introdução

A implantação contínua (CD) é a etapa em que o software validado é entregue a um ambiente onde pode ser executado.

Pense novamente na nossa fábrica de software.

1. CI: o robô verifica se existem defeitos.
2. Artefato: o robô embala o produto em uma caixa.
3. CD: o caminhão de entrega leva a caixa até a loja (servidor), para que os clientes possam usá-la.

No mundo real, a implantação geralmente significa atualizar sistemas em execução por meio de SSH, APIs ou mecanismos de release específicos da plataforma. Neste laboratório, você simulará esse processo, mas a principal lição é entender o fluxo de entrega, desde o código testado até o ambiente em execução.

Essa é a principal diferença entre CI e CD. A CI comprova que as alterações no software estão saudáveis o suficiente para serem enviadas, enquanto a CD gerencia a movimentação controlada dessas alterações validadas para um ambiente.

Neste laboratório, você aprenderá a:

• Entender o conceito de gatilhos manuais (implantação com um clique).
• Escrever um workflow de implantação que simula o processo real.
• Conectar seu "caminhão de entrega" (CD) ao seu "controle de qualidade" (CI).

Pré-requisitos

Continuaremos usando o repositório github-actions-basics.

Criar uma implantação manual

Às vezes, você não quer implantar o código toda vez que fizer push. Talvez seja necessário aguardar uma aprovação ou implantar somente quando você estiver pronto.

Por isso, gatilhos manuais e ambientes em etapas são comuns. Os pipelines de entrega geralmente equilibram velocidade e cautela operacional, em vez de implantar imediatamente cada build bem-sucedido em produção.

O GitHub Actions permite criar workflows que são executados somente quando você clica em um botão. Isso é feito usando o gatilho workflow_dispatch.

Acesse o diretório de workflows do projeto.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Observação: substitua your-username pelo seu nome de usuário real do GitHub.

Crie um novo arquivo chamado deploy.yml.

touch .github/workflows/deploy.yml

Abra o arquivo com o nano.

nano .github/workflows/deploy.yml

Adicione o conteúdo a seguir:

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

Veja on: workflow_dispatch? Esse é o botão mágico.

Salve e saia do nano. Em seguida, envie esse arquivo para o GitHub.

git add .
git commit -m "Add manual deployment workflow"
git push

Agora, acesse a aba Actions no GitHub.

1. Clique em Deploy to Production na barra lateral esquerda.
2. Você verá um banner azul com a mensagem "This workflow has a dispatch event trigger."
3. Clique no botão Run workflow e, depois, no botão verde Run workflow no menu suspenso.

Você acabou de acionar manualmente um pipeline de implantação!

Simular as etapas de implantação

Os scripts de implantação reais podem ser complexos, mas geralmente seguem um padrão simples:

1. Conectar-se ao servidor.
2. Baixar a nova versão do software.
3. Reiniciar a aplicação.

Mesmo quando os detalhes de implementação variam, a maioria dos pipelines de implantação ainda segue essa estrutura geral: autenticar, obter o artefato desejado e fazer com que o ambiente em execução o utilize.

Vamos atualizar o arquivo deploy.yml para simular essas etapas. Usaremos comandos echo para mostrar o que aconteceria.

Abra o arquivo novamente.

nano .github/workflows/deploy.yml

Substitua a seção jobs por esta simulação mais detalhada:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

Salve e saia. Envie suas alterações.

git add .
git commit -m "Update deployment steps"
git push

Volte ao GitHub Actions e execute manualmente o workflow Deploy to Production novamente. Observe os logs. Eles se parecem muito com uma implantação real!

Essa técnica de "Mock" é realmente muito útil. No mundo profissional, geralmente escrevemos primeiro esses workflows "Skeleton" para definir o processo antes de desenvolver o código complexo de fato.

Adicionar verificações de segurança

No momento, nosso workflow de "Deploy" está completamente separado do workflow de "Test" (CI). Mas, na vida real, você nunca deve implantar código com defeitos. O caminhão de entrega só deve partir se a verificação de qualidade for aprovada.

Podemos vincular workflows usando a palavra-chave needs, mas isso funciona melhor dentro de um único arquivo. Para arquivos separados, normalmente gerenciamos essa dependência por meio do processo: a CI é executada no Push, enquanto a CD é executada no Release ou manualmente.

No entanto, vamos aprender a adicionar uma verificação de segurança até mesmo à nossa implantação manual. Vamos considerar que só queremos implantar quando tivermos certeza absoluta.

Abra o arquivo deploy.yml.

nano .github/workflows/deploy.yml

Vamos adicionar uma simulação de proteção de environment. Modifique a seção steps para incluir uma pausa.

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

(Observação: em uma configuração Enterprise verdadeira, usaríamos um recurso chamado GitHub Environments para exigir que a "CI seja aprovada" antes que esse job pudesse ser executado, mas isso requer uma configuração externa a este arquivo.)

Por enquanto, salve e saia. Em seguida, envie suas alterações.

git add .
git commit -m "Add safety check"
git push

Execute o workflow manualmente uma última vez.

Resumo

Parabéns! Você concluiu o módulo de CICD do GitHub Actions.

Neste laboratório final, você aprendeu:

• Gatilhos manuais: como usar workflow_dispatch para controlar implantações.
• Simulação: como criar um protótipo de um processo de implantação usando etapas simuladas.
• Visão geral: como CI, artefatos, segurança e CD se integram.

Você começou sem nenhum conhecimento sobre GitHub Actions e agora tem um repositório totalmente funcional, com scripts automatizados de teste, empacotamento e implantação. Você está pronto para começar a automatizar seus próprios projetos!