DS & II

Capítulo 03 - Integração Contínua

Leitura de 4 min

🚀 Capítulo 03: Integração Contínua (CI) (Tema: Homem de Ferro)

NOTE

Este capítulo utiliza a temática de Homem de Ferro para explicar a Integração Contínua. O Jarvis testa cada peça nova da armadura automaticamente para garantir que o Tony Stark não caia lá do alto!

1. 🎯 Objetivo da Aula

Compreender o conceito de Integração Contínua (CI - Continuous Integration), entendendo como funcionam os testes automatizados e o processo de build a cada commit.

2. 🏢 O Cenário Prático (Seu Desafio)

Tony Stark está sempre atualizando a armadura do Homem de Ferro. Ele não espera a armadura ficar pronta para testar tudo de uma vez.

  • O Jarvis (a inteligência artificial) fica vigiando o projeto.
  • Assim que Tony altera o código do propulsor da bota, o Jarvis roda uma simulação matemática para ver se aquela mudança quebrou o sistema de voo.
  • Se o teste falhar, o Jarvis avisa na hora: “Senhor, o novo propulsor vai fazer o senhor cair”.

No desenvolvimento de software, a Integração Contínua (CI) é o nosso Jarvis! Toda vez que você envia código novo para o repositório (GitHub), um robô pega o código e roda todos os testes automaticamente. Se o código novo quebrar o sistema, o robô avisa a equipe na hora! Seu desafio é configurar o seu Jarvis!

3. 🧠 Fundamentos: A Teoria Traduzida

CI (Continuous Integration) é a prática de integrar alterações de código de múltiplos desenvolvedores em um repositório compartilhado várias vezes ao dia.

🤖 O Fluxo da CI:

  1. Commit: O programador termina uma pequena tarefa e envia o código (git push).
  2. Trigger (Gatilho): O servidor de CI (Ex: GitHub Actions) percebe que há código novo.
  3. Build: O servidor baixa o código e “monta” o projeto (compila, baixa bibliotecas).
  4. Test: O servidor roda todos os testes automatizados (unitários, integração).
  5. Feedback: Se passar em tudo, fica verde (Sucesso). Se falhar, fica vermelho (Quebrou o build).

🏆 Vantagens:

  • Descobrimos bugs no mesmo dia em que foram criados (muito mais fácil de corrigir).
  • A base de código principal (main) está sempre funcionando e pronta para uso.

4. 📖 Exemplo Guiado: O Arquivo do Jarvis (YAML)

No GitHub, usamos um arquivo de texto com a extensão .yml para dizer para o Jarvis o que ele deve fazer. Veja um exemplo simples:

# Arquivo .github/workflows/jarvis.yml
name: Testes do Jarvis
 
on: [push] # Executa toda vez que alguém der push
 
jobs:
  testar:
    runs-on: ubuntu-latest
    steps:
      - name: Baixar o código
        uses: actions/checkout@v2
        
      - name: Instalar o Node.js
        uses: actions/setup-node@v2
        
      - name: Rodar os Testes
        run: npm test # Executa os testes do projeto

5. 🛠️ Prática Obrigatória 1: O Build Quebrou!

Imagine que você deu push no seu código e o ícone no GitHub ficou vermelho (X) dizendo que o build falhou no teste de login.

  1. O que você deve fazer? Ignorar e continuar programando ou parar tudo e corrigir o erro?
  2. Por que deixar o build quebrado por muitos dias é considerado uma má prática grave em equipes DevOps?

6. 🛠️ Prática Obrigatória 2: O Pré-requisito da CI

Para que a Integração Contínua funcione de verdade e o robô consiga dizer se o código está bom ou ruim:

  1. O que o projeto obrigatoriamente precisa ter escrito pelos programadores? (Dica: O robô não adivinha se o código funciona, ele precisa executar algo para validar).

7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 03 DevOps) e clique em Commit to main.
  2. Envie para a Nuvem (Push): Clique em Push origin.

8. 📂 Estrutura de Pastas

mod_13_devops_e_cloud/
├── .github/
│   └── workflows/
│       └── jarvis.yml
└── capitulos/
    └── capitulo_03_ci.md

💡 Checkpoint de Lógica

A CI garante que o código está bom. Mas ela não coloca o código no ar para o cliente usar ainda! Esse será o papel da CD (Continuous Delivery), que veremos no próximo capítulo.

10. 🔥 Desafio de Fixação

Pesquise sobre outras ferramentas famosas de CI além do GitHub Actions (Ex: Jenkins, GitLab CI, CircleCI).

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. Parar tudo e corrigir o erro imediatamente. O código quebrado não deve ser deixado lá.
  2. Porque outros programadores vão baixar o código quebrado e não conseguirão trabalhar. A base do projeto deve estar sempre funcional. Gabarito da Prática 2:
  3. O projeto precisa ter Testes Automatizados escritos! Se não houver testes para o robô executar, ele apenas dirá que o código compila, mas não saberá se a lógica está certa.

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks