O CI/CD é a espinha dorsal técnica do DevOps. É o conjunto de práticas que automatizam o caminho entre « o código escrito por um programador » e « a aplicação que corre em produção ».
| Sigla | Nome | Numa frase |
|---|---|---|
| CI | Integração contínua (Continuous Integration) | Funde-se e testa-se o código com frequência e automaticamente. |
| CD | Entrega contínua (Continuous Delivery) | O código testado está sempre pronto a ser implementado (ida a produção manual). |
| CD | Implementação contínua (Continuous Deployment) | O código testado parte automaticamente para produção. |
Sem CI/CD, entregar software parece uma mudança de casa à mão: lenta, cansativa e arriscada. Com CI/CD, é um tapete rolante automatizado: põe-se o código num extremo, a aplicação chega pronta no outro.
Mini-exercício — Ligue cada sigla à sua definição: (1) CI, (2) Continuous Delivery, (3) Continuous Deployment.
(1) CI = fusão + build + testes automáticos frequentes. (2) Continuous Delivery = sempre pronto a implementar, botão manual para a prod. (3) Continuous Deployment = ida a produção automática após testes bem-sucedidos.
A integração contínua consiste em fundir frequentemente o código de todos os programadores numa branch comum, e em validar automaticamente cada fusão por um build e testes.
| Sem CI | Com CI |
|---|---|
| Funde-se tudo no fim do mês → conflitos grandes e dolorosos | Funde-se várias vezes por dia → conflitos pequenos e fáceis |
| Os bugs são descobertos tarde | Os bugs são descobertos em minutos |
| « Funcionava na minha máquina » | Build reproduzível no servidor |
Analogia: arrumar a cozinha à medida que se cozinha (CI) em vez de esperar que tudo esteja sujo (integração « big bang »). O pequeno esforço frequente evita a catástrofe rara.
Mini-exercício — Um programador guarda o código 3 semanas sem o fundir, depois tenta um merge grande. Que princípio de integração contínua não respeitou, e que consequência é provável?
Não fundiu com frequência. Consequência provável: um conflito de fusão massivo e difícil de resolver, e bugs detetados muito tarde. A CI recomenda fusões pequenas e frequentes.
Os dois « CD » parecem-se mas diferem num único ponto: quem carrega no botão da ida a produção.
| Continuous Delivery | Continuous Deployment | |
|---|---|---|
| Ida a produção | Manual (um humano clica) | Automática |
| Controlo | Decisão final humana | Nenhuma intervenção |
| Ideal para | Setores regulamentados, releases planeadas | Equipas maduras, forte taxa de testes |
Continuous Delivery = o carro está estacionado à porta, pronto, chaves no contacto; você decide quando arrancar. Continuous Deployment = o carro autónomo arranca sozinho assim que está pronto.
Mini-exercício — Um banco quer que cada ida a produção seja aprovada por um responsável. Qual « CD » escolher?
Continuous Delivery: o pipeline deixa a versão pronta automaticamente, mas a ida a produção continua a ser uma decisão humana (validação do responsável).
Um pipeline é uma sucessão de etapas automatizadas (chamadas stages) que transformam o código-fonte numa aplicação implementada. Se uma etapa falha, o pipeline pára e a equipa é notificada.
| Stage | Papel | Exemplo de ferramenta |
|---|---|---|
| Checkout | Obter o código a partir do Git | Git |
| Build | Compilar / montar | Maven, npm, javac |
| Test | Verificar automaticamente | JUnit, pytest |
| Package | Produzir um artefacto entregável | .jar, imagem Docker |
| Staging | Implementar em pré-produção | servidor de teste |
| Deploy | Ir a produção | servidor / cloud |
O princípio do « fail fast »: colocam-se as etapas rápidas e baratas (compilação, testes unitários) primeiro. Não faz sentido implementar se o código nem sequer compila.
Mini-exercício — Em que ordem colocar estes stages: Deploy, Build, Test, Checkout?
Checkout → Build → Test → Deploy. Obtém-se o código, compila-se, testa-se, e só se implementa se tudo estiver verde.
Sigamos o percurso de uma única linha de código corrigida por uma programadora, a Léa, numa aplicação web.
Desenrolar passo a passo:
git push.v1.4.1.Compare: antes do CI/CD, a mesma correção teria exigido uma ida a produção planeada, à noite, à mão, com o stress do « oxalá funcione ». Aqui, é uma rotina de 6 minutos.
Mini-exercício — Na etapa 3, 2 testes em 124 falham. O que faz o pipeline, e a versão parte para produção?
O pipeline pára no stage Test, notifica a Léa, e não implementa. A produção fica na versão estável anterior. É o princípio « fail fast » que protege a prod.
| Vantagem | O que muda concretamente |
|---|---|
| Menos erros humanos | As tarefas repetitivas são escritas em scripts: sem esquecimento de etapa |
| Feedback rápido | Sabe-se em minutos se uma alteração parte alguma coisa |
| Implementações frequentes | Pode-se entregar várias vezes por dia com confiança |
| Reprodutibilidade | Cada build é idêntico — acabou o « funciona na minha máquina » |
| Rastreabilidade | Cada alteração fica registada: quem, o quê, quando |
Quanto mais se implementa, mais cada implementação é pequena, portanto menos arriscada. É contra-intuitivo: implementar mais vezes torna as implementações mais seguras, não mais perigosas.
Mini-exercício — Cite duas razões pelas quais implementar 10 vezes por dia pequenas alterações é menos arriscado do que uma única implementação grande por mês.
Question 1: O que significa « CI »?
a) Code Inspection
b) Continuous Integration
c) Container Initialization
d) Central Infrastructure
Resposta: b) — Continuous Integration: fusão e validação automáticas frequentes do código.
Question 2: Qual é a diferença entre Continuous Delivery e Continuous Deployment?
a) Nenhuma, são sinónimos
b) Em Delivery a ida a prod é manual; em Deployment é automática
c) O Deployment não faz testes
d) A Delivery implementa automaticamente
Resposta: b) — Os dois preparam uma versão pronta; só a ida a produção difere (manual vs automática).
Question 3: O que acontece se o stage Test falhar num pipeline?
a) O pipeline continua na mesma até à produção
b) O pipeline pára e a equipa é notificada
c) O código é apagado do repositório
d) O pipeline recomeça até ao infinito
Resposta: b) — Princípio « fail fast »: uma falha pára o pipeline e dispara um alerta; nada parte para produção.
Question 4: O que é um artefacto num pipeline?
a) Um bug introduzido por engano
b) O resultado empacotado de um build (ex. um .jar, uma imagem)
c) Uma mensagem nos logs
d) Um utilizador do sistema
Resposta: b) — O artefacto é o entregável produzido pelo build, pronto a ser implementado.
Question 5: Por que implementar com frequência torna as implementações mais seguras?
a) Porque cada implementação é mais pequena e portanto mais fácil de diagnosticar e anular
b) Porque se suprimem os testes
c) Porque os servidores ficam mais potentes
d) Porque os utilizadores não se apercebem
Resposta: a) — Alterações pequenas e frequentes reduzem a superfície de risco e facilitam o rollback.
Uma equipa desenvolve uma aplicação Java. Conceba (em papel / em pseudo-pipeline) os stages de um pipeline CI/CD para esta aplicação, indicando para cada stage: o nome, o papel, e o que deve parar o pipeline. Precise também se recomenda Continuous Delivery ou Continuous Deployment, e porquê.
| Ordem | Stage | Papel | Condição de paragem |
|---|---|---|---|
| 1 | Checkout | Obter o código a partir do Git | Repositório inacessível |
| 2 | Build | Compilar com Maven (mvn package) | Erro de compilação |
| 3 | Test | Lançar os testes JUnit | Um teste falha |
| 4 | Package | Produzir o artefacto .jar / imagem | Falha de empacotamento |
| 5 | Staging | Implementar em pré-produção | Arranque aplicacional KO |
| 6 | Deploy | Ir a produção | Validação manual recusada |
Escolha recomendada para começar: Continuous Delivery.
Justificação: enquanto a cobertura de testes não estiver madura, mantém-se uma validação humana antes da produção (Delivery). Quando a equipa confia nos testes automatizados, pode passar a Continuous Deployment (ida a prod automática).
Esquema esperado:
Lição 04 — Estratégias de implementação: como passar da v1 à v2 em produção sem partir o serviço (Blue/Green, Canary, Rolling…).
Todos os direitos reservados. Qualquer reprodução, difusão, utilização ou adaptação deste curso, no todo ou em parte, é estritamente proibida sem a autorização escrita prévia do Dr. Haythem REHOUMA.
Curso criado por Dr. Haythem REHOUMA — Desenvolvimento e implementação de soluções de dados