Pipelines de CI/CD: diferença entre CI e CD, Jenkins e GitHub Actions

Pipelines de integração e entrega contínua são o coração da automação de software. Nesta amostra, você vê três pontos que mais caem em prova: a divisão de funções entre CI e CD, os tipos de código que cada pipeline pode processar e o papel dos testes de segurança. Ferramentas como Jenkins e GitHub Actions executam esses fluxos, mas a banca cobra o conceito, e não a sintaxe de cada uma.

Ponto 1: CI e CD têm funções diferentes

Um pipeline de CI/CD é um fluxo de trabalho que leva o código-fonte do desenvolvedor por etapas como build (compilação), testes, empacotamento, implantação e operação. Esse fluxo é apoiado por ferramentas automatizadas e por mecanismos de feedback, que avisam a equipe quando algo falha.

As três primitivas são:

• Integração contínua (CI): integrar e testar o código com frequência, por meio de build e testes automáticos.
• Entrega contínua (CD): deixar o software pronto para ser entregue a qualquer momento.
• Implantação contínua (CD): colocar o software em produção de forma automática.

Na prática, o CI puxa o código do repositório, invoca o build, aciona as ferramentas de teste e grava os artefatos testados no registro de imagens. Já o CD retira esses artefatos, empacota e implanta conforme a infraestrutura descrita em código.

💡 Dica: pense em CI como "puxa, compila, testa e guarda" e em CD como "retira, empacota e implanta". Assim você não confunde as duas siglas.

⚠️ Pegadinha: a banca costuma inverter as funções. Quem grava os artefatos testados no registro de imagens é o CI. Quem retira esses artefatos e faz o deploy é o CD.

Jenkins e GitHub Actions descrevem esses fluxos como código e os guardam junto com a aplicação. Em um, o pipeline costuma ficar em um arquivo de definição no próprio projeto; no outro, em arquivos de workflow no repositório. Em prova, o que importa é a função de cada etapa, não qual ferramenta a executa.

Ponto 2: os cinco tipos de código

A banca gosta de cobrar a classificação do que vai para o pipeline. Podem ser criados pipelines separados para cinco tipos de código:

1. Código da aplicação: lógica que executa funções de negócio.
2. Código de serviços da aplicação: sessão, conexão e recursos de rede, como descoberta de serviços, rotas, resiliência e autenticação em um service mesh.
3. Infraestrutura como código (IaC): recursos de computação, rede e armazenamento descritos em código declarativo.
4. Política como código: regras de segurança em tempo de execução, como as da abordagem zero trust.
5. Observabilidade como código: logging, tracing e monitoramento da saúde da aplicação.

📌 Cai muito: IaC, política como código e observabilidade como código formam o código declarativo. Eles recebem o mesmo tratamento do código da aplicação: são versionados, documentados e têm controles de acesso definidos.

⚠️ Pegadinha: os tipos 3, 4 e 5 podem se sobrepor ao tipo 2. Não são compartimentos estanques, e uma mesma configuração pode pertencer a mais de uma categoria.

Como a IaC chega à infraestrutura

A linguagem declarativa modela a infraestrutura como um conjunto de recursos. A ferramenta de gestão de configuração reúne esses recursos e gera manifestos, que definem a forma e o estado finais da plataforma. Esses manifestos costumam ser codificados em formato neutro de plataforma, como o JSON, e enviados aos agentes de provisionamento por REST APIs.

Ponto 3: testes de segurança no pipeline

As ferramentas de teste de segurança citadas são SAST, DAST e SCA. Elas identificam vulnerabilidades e bugs por meio de varreduras. Uma forma prática de memorizar: o SAST analisa o código estático, o DAST testa a aplicação em execução e o SCA verifica as dependências de terceiros.

• SAST, DAST e SCA também podem ser aplicados ao IaC, já que ele define a arquitetura de implantação. Assim, falhas de projeto de segurança podem ser avaliadas e corrigidas de forma automática.
• Em algumas plataformas, essas ferramentas se integram às IDEs e às demais ferramentas DevOps, ficando transparentes ao desenvolvedor.

📌 Cai muito: SAST, DAST e SCA são as ferramentas de teste de segurança do pipeline, e o IaC também pode ser testado por elas.

⚠️ Pegadinha: a segurança não se limita ao build e à implantação. Em produção, há monitoramento contínuo, alertas e mecanismos de correção, o que apoia a autorização contínua para operar (C-ATO).

Resumo para a prova

🧠 Memorize: CI puxa, compila, testa e guarda. CD retira, empacota e implanta. Os cinco tipos de código passam por pipelines, e o código declarativo é versionado, documentado e controlado.

Continue estudando

A aula completa, os mapas mentais e os flashcards com repetição espaçada deste tema estão no plano do MemorizeCards. Veja as opções em ver os planos e explore outros temas em ver o catálogo.