Seja honesto: quantas vezes você já terminou uma feature incrível, testou na sua máquina, e na hora de colocar em produção teve que rodar uma dezena de comandos manuais no terminal? Ou pior, teve que zipar pastas e arrastar para um servidor via FTP?
Fazer deploy manual não é apenas chato; é uma receita garantida para erros humanos. Esquecer de rodar os testes, subir com a connection string errada ou esquecer de instalar um pacote novo são clássicos do desenvolvimento de software.
Nesta série, vamos resolver isso de uma vez por todas. Hoje, na Parte 1, vamos criar um "robô" no GitHub Actions que vai testar e compilar sua aplicação Full-Stack (Frontend e Backend) em paralelo toda vez que você fizer um push.
O que é CI/CD de forma simples?
Esqueça as definições acadêmicas complexas:
- CI (Continuous Integration): É a garantia de que o seu código novo não quebrou o que já funcionava. Nosso pipeline vai baixar o código e rodar o build e os testes automaticamente.
- CD (Continuous Deployment): Se o CI passar e tudo estiver verde, o código é enviado automaticamente para o servidor de produção.
O Cenário Real: Angular + C# (.NET)
Em vez de um tutorial genérico com um site estático, vamos simular a vida real. Temos um repositório com uma API robusta em C# (.NET) e um Frontend dinâmico em Angular.
Queremos que o GitHub Actions rode os dois processos simultaneamente para economizar tempo.
Criando o nosso Workflow
No seu repositório, crie um arquivo no seguinte caminho: .github/workflows/main.yml. É aqui que a mágica acontece.
name: Full-Stack CI/CD Pipeline
# Quando esse robô deve trabalhar?
on:
push:
branches: [ "main" ] # Roda sempre que houver código novo na main
jobs:
# JOB 1: O Frontend (Angular)
build-frontend:
name: Build Angular App
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./frontend
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '22'
- name: Install Dependencies & Build
run: |
npm ci
npm run build
# JOB 2: O Backend (.NET C#) - Roda em paralelo com o Frontend!
build-backend:
name: Build & Test .NET API
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./backend
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
- name: Restore, Build, and Test
run: |
dotnet restore
dotnet build --no-restore
dotnet test --no-build --verbosity normal
env:
# Injetando variáveis de ambiente seguras no ambiente de teste
DB_CONNECTION: ${{ secrets.DB_CONNECTION_STRING }}
# JOB 3: O Deploy (Só roda se os dois de cima passarem)
deploy:
name: Deploy to Production
needs: [build-frontend, build-backend] # A regra de ouro
runs-on: ubuntu-latest
steps:
- name: Deploying Magic
run: echo "🚀 Fazendo deploy seguro para o servidor..."
# Aqui entrariam os scripts da sua nuvem (AWS, Azure, Vercel, etc.)
Entendendo a anatomia do YAML
Se você nunca lidou com GitHub Actions, essas palavras podem parecer confusas. Vamos traduzir o que acabamos de escrever:
on: Define o "gatilho" (trigger). É aqui que dizemos ao GitHub quando rodar nosso pipeline. No nosso caso, configuramos push na branch main. Ou seja: enviou código novo para a main, o robô acorda.
jobs: São as tarefas maiores que precisam ser feitas. Cada job (como build-frontend e build-backend) roda em um ambiente isolado. Por padrão, se você não disser o contrário, o GitHub tenta rodar todos os jobs ao mesmo tempo.
runs-on: Diz ao GitHub qual sistema operacional queremos usar. ubuntu-latest significa que o GitHub vai nos emprestar uma máquina virtual Linux novinha e limpa para cada execução.
steps: É a receita do bolo. É a lista sequencial de passos que devem ser executados dentro de um Job.
uses: Quando usamos uses, estamos pegando "atalhos" — ações pré-fabricadas pela comunidade. Por exemplo, actions/checkout@v4 é uma ação pronta que diz: "baixe o código desse repositório para dentro da máquina virtual".
run: É aqui que você digita comandos de terminal, exatamente como faria na sua máquina local (ex: npm run build ou dotnet test).
O Poder do Paralelismo e a Regra do Deploy
Repare que dividimos nossa automação em partes estratégicas:
-
Paralelismo: Como colocamos
build-frontendebuild-backendcomo jobs separados, o GitHub Actions vai rodar os dois ao mesmo tempo. Isso corta o tempo do seu CI pela metade!
Como você pode ver, enquanto o Angular é compilado, a API .NET já está sendo construída e testada.
-
A Regra do Deploy (
needs): O job dedeploytem a propriedadeneeds: [build-frontend, build-backend]. Isso significa que ele vai esperar os dois builds terminarem.
Se o teste do C# quebrar, o deploy é cancelado e o código com bug não vai para produção. Tudo verde? O deploy é liberado!
Você também pode inspecionar cada etapa clicando nos jobs. É fantástico ver seus comandos sendo executados passo a passo em uma máquina virtual limpa:
Os logs mostram detalhadamente desde o setup do .NET até a execução dos testes.
Segurança Real: O uso de Secrets
No job do Backend, usamos ${{ secrets.DB_CONNECTION_STRING }}.
Nunca suba credenciais, senhas ou chaves de API no seu código-fonte!
Para passar essas informações de forma segura para o GitHub Actions:
- Vá na aba Settings do seu repositório no GitHub.
- Na barra lateral, clique em Secrets and variables > Actions.
Acessando a área de configuração segura do repositório.
- Clique no botão verde New repository secret.
- Defina o nome (exatamente como você chamou no arquivo YAML) e cole o valor real da sua string de conexão.
O valor inserido aqui é criptografado e nunca mais poderá ser lido diretamente, apenas atualizado ou apagado.
Uma vez salvo, o GitHub Actions vai injetar essa senha dinamicamente durante a execução, mantendo seus dados a salvo!
Secret configurado com sucesso.
E agora?
Missão cumprida! Com esse workflow, você elevou o padrão tecnológico do seu projeto. Ter um processo de validação automatizado garante que o seu código seja testado de forma isolada, limpa e padronizada.
Mas há um detalhe que ninguém te conta quando você começa a automatizar tudo: o limite gratuito.
O GitHub te dá 2.000 minutos grátis por mês para rodar essas Actions. Com uma aplicação Full-Stack e a equipe crescendo, esses minutos evaporam rápido. Quando a cota acaba, a conta chega (literalmente).
No próximo episódio da série, vou te ensinar como fugir dessa limitação hospedando um robô do GitHub (Self-Hosted Runner) de graça na sua própria máquina ou em uma VPS barata. Não perca!
Top comments (0)