Módulo 1: O que é CI/CD, sem jargão

Imagine uma cozinha de restaurante. Toda vez que um cozinheiro termina um prato, antes de ir pra mesa ele passa por uma bancada onde alguém sempre confere: está na temperatura certa? tem o que o pedido pediu? está bem apresentado? Se algo está errado, o prato volta na hora: não chega no cliente.

CI/CD é essa bancada de conferência, automática, para software. Toda vez que alguém muda o código, uma máquina pega essa mudança e roda uma checagem completa antes de deixar a mudança "ir pra mesa" (ser aceita no projeto ou publicada).

A diferença pro mundo real: a bancada nunca cansa, nunca esquece um passo, e confere toda mudança, até a de uma linha.

Não decore, entenda a ideia de cada parte:

• CI: Integração Contínua (Continuous Integration): cada mudança de código é juntada ao projeto e testada na hora, várias vezes por dia, em vez de acumular semanas de trabalho e testar tudo de uma vez no fim (quando achar o que quebrou vira um pesadelo).
• CD: Entrega Contínua (Continuous Delivery): se a checagem passou, o sistema já deixa pronto pra publicar, às vezes publica sozinho (Continuous Deployment), às vezes só espera alguém apertar um botão.

Nesta trilha o foco é o CI: rodar os testes sozinho a cada mudança. É a parte que mais afeta o dia a dia de QA e a que aparece em quase toda vaga.

Pipeline é só o nome da lista de passos que a máquina executa, na ordem, a cada mudança. Um pipeline de testes típico faz:

1. Pega a versão mais recente do código
2. Instala as dependências  (pip install / npm install ...)
3. Roda os testes           (pytest, k6, lint ...)
4. Deu tudo certo?
   sim  -> marca a mudança com um  check verde
   nao  -> marca com um  X vermelho  e avisa quem mexeu

Cada passo é um comando de terminal, os mesmos que você rodaria na sua máquina. O pipeline só automatiza a sequência e roda num computador limpo, igual pra todo mundo. É por isso que ele mata a frase "mas na minha máquina funciona": não existe "a minha máquina", existe a máquina do pipeline.

O valor real do CI é o tempo até você descobrir que quebrou.

Sem CI	Com CI
alguém mexe no código	alguém mexe no código
ninguém roda todos os testes	o pipeline roda todos os testes em ~1–3 min
o bug entra no projeto	o pipeline marca ✗ e aponta o teste que falhou
dias depois, QA acha na mão	quem mexeu conserta antes de a mudança ser aceita
caçar a causa no meio de 20 mudanças	a causa é a única mudança daquele ✗

Achar o defeito 2 minutos depois de ele nascer, isolado, é incomparavelmente mais barato do que achá-lo uma semana depois no meio de tudo.

Neste projeto o pipeline roda no GitHub Actions, a ferramenta de CI embutida no GitHub, de graça pra repositório público. Você a vê em dois lugares:

• Aba "Actions" do repositório: a lista de todas as execuções (chamadas de runs). Cada linha é um disparo do pipeline, com ✓ ou ✗, quem disparou e quanto tempo levou. Clicando numa, você vê cada passo e o log (a saída do terminal) de cada um.
• Dentro de um Pull Request: lá embaixo, um quadro "checks" mostra ✓/✗ do pipeline pra aquela proposta de mudança. É o que um revisor olha antes de aceitar.

O arquivo que descreve o pipeline mora no próprio repositório, em .github/workflows/. Neste projeto: trilha-3-pytest.yml e trilha-5-k6.yml. O Módulo 2 abre o primeiro linha a linha.

• CI: a prática de testar cada mudança automaticamente.
• Pipeline / workflow: a lista de passos que roda a cada mudança.
• Run: uma execução do pipeline (um disparo).
• Job: um bloco de passos que roda numa máquina. Um pipeline pode ter vários.
• Step / passo: um comando dentro de um job.
• Runner: a máquina (aqui, virtual, na nuvem do GitHub) que executa o job.
• Build vermelho / quebrado: um run que terminou em ✗.
• Check: o resultado ✓/✗ que o pipeline "cola" numa mudança ou PR.

O GitHub Actions só roda se o código estiver num repositório no GitHub, e precisa ser o repositório inteiro (com a pasta .github/workflows/ junto), não só a pastinha da trilha que você baixou. O jeito certo é dar fork: uma cópia completa do projeto, na sua conta, que já vem com os workflows prontos, nada de subir arquivo por arquivo.

1. Crie uma conta grátis em github.com, se ainda não tiver.
2. Abra a página do repositório deste projeto no GitHub e clique no botão Fork (canto superior direito). Isso cria github.com/SEU-USUARIO/HardSkillsQA, uma cópia só sua, separada da original. Mexer nela não afeta o projeto de ninguém.
3. Traga essa cópia pra sua máquina: instale o GitHub Desktop e use "Clone a repository" apontando pro seu fork, ou rode no terminal git clone com a URL do seu fork.
4. Abra a pasta clonada no VS Code. A partir daí a aba Actions do seu fork já aparece sozinha, com os dois workflows (trilha-3-pytest.yml e trilha-5-k6.yml) prontos pra rodar.

Sem escrever nada ainda, só explorar:

1. Abra o seu repositório no GitHub e clique na aba Actions.
2. Ache um run do workflow "Trilha 3: pytest" e abra.
3. Clique no job pytest. Você vê a lista de passos: checkout, setup-python, Instalar dependências, Rodar os testes.
4. Expanda "Rodar os testes" e leia o log: é a mesma saída do pytest que você viu no seu terminal na Trilha 3.
5. Repare no topo: quem disparou, por qual commit, ✓ ou ✗, e o tempo total.

Se a aba Actions estiver vazia: o pipeline roda quando algo dentro de trilha-3/ muda. Vá ao Módulo 3 pra provocar um run de propósito.

Olhar de QA

O CI não melhora a qualidade sozinho: ele encurta o tempo até você descobrir que algo quebrou, e isso muda tudo. Como QA, o argumento que você leva para o time não é técnico, é de custo: achar o defeito dois minutos depois, isolado numa única mudança, é incomparavelmente mais barato do que achá-lo uma semana depois no meio de vinte. E cuidado com a leitura ingênua do verde: ✓ diz que aqueles testes passaram, não que a mudança está correta.