Trabalhando nestes últimos meses, me questionei a respeito de alguns assuntos:

Quais seriam as melhores práticas de uma pipeline?
Quais estágios essa pipeline deve ter?
Devemos nos preocupar apenas com CI/CD ou existem estágios que antecedem e sucedem o CI/CD?
Quanto tempo deve durar uma pipeline?

Fiquei refletindo sobre essas perguntas, já que existem diversas ferramentas que podem ser integradas a uma pipeline, diversos tipos de testes, diferentes formas de deploy e afins.

Gostaria de usar este artigo para esclarecer quais componentes mínimos são necessários em uma pipeline. A ideia não é apresentar isso como uma verdade absoluta, mas sim como um guia prático que pode ajudá-lo a garantir entregas de software com qualidade.

Etapas de uma pipeline

Analisando as pipelines do dia a dia, discussões no Stack Overflow e Reddit, além de ler alguns artigos sobre o tema, identifiquei que uma pipeline pode ser dividida em 5 etapas principais.

Source Control & Triggers
Continuous Integration (CI)
Infrastructure & Orchestration
Continuous Deployment (CD)
Observability & Monitoring

Source Control & Triggers

É uma etapa mais focada em governança, processo humano, políticas e regras organizacionais. Dentro deste contexto existem alguns pontos interessantes que merecem um pouco de atenção:

Git Repository
- Etapa em que você vai definir qual plataforma será usada (AzureDevops, Gitlab, Github,etc).
- Pode implementar regras de proteção em branches.
Webhook Triggers
- Dispara um evento, sendo ele um alerta por exemplo na sua caixa de e-mail, caso tenha ocorrido um push, commit ou eventos merge.
Code Reviews
- Manuais: você estabelece políticas que exigem um número mínimo de aprovações de revisores qualificados antes que um Pull Request (PR) possa ser merged para a branch principal.
- Automáticos: utilizam pipelines de CI/CD para executar validações antes do merge, estabelecendo quality gates obrigatórios. Exemplos incluem: cobertura mínima de 80% em testes unitários e máximo de 4 vulnerabilidades de segurança. Esses thresholds são configuráveis conforme a maturidade do projeto. A implementação dessas automações será detalhada no próximo tópico.

Continuous Integration (CI)

É o coração da automação de qualidade do código.

Pré build
- Conventional Commits: Verificação do formato (feat:, fix:, docs:, etc.)
- Prettier: verificação de formatação ou formatação automática.
- Semantic Release Validation: verificação da semâtica, releases automáticos baseado nos commits.
- Lint: o objetivo é detecta variável não utilizada, função sem retorno, imports não usados. A finalidade é encontrar código morto e elementos não utilizados no código.
- Unit test (testes unitários): verifica se as funções/métodos funcionam corretamente. Exemplo testar se uma função de soma retorna o resultado esperado.
Build & Compilação
- Nessa etapa fazemos a instalação das dependências e bibliotecas necessárias, transforma o código em um arquivo executável e ocorre a geração de arquivos ou artefatos para os próximos estágios.
Pós build
- Teste de cobertura: verifica quanto do seu código está coberto por testes, identificando áreas não testadas.
- Security Scanning: verifica se seu código tem alguma vulnerabilidade, hardcoded. Você pode usar o Sast para fazer essa verificação.
- Sonarqube: ferramenta que faz anaálises códigos duplicados, code smell, detecta bugs, vulnerabilidades e pode ser integrada a outras ferramentas.
Container Build & Artefatos
- Utilização de containeres para criar uma imagem da aplicação, sempre é recomendado fazer um multi-stage build.
- Nessa etapa é possivel fazer um scanning de vulnerabilidade da imagem.
- Depois é recomendado que você salve essa imagem gerada em algum registry. Ecr, Acr ou até mesmo no docker.io.

Infrastructure & Orchestration

Estágio de provisionamento da infraestrutura necessária.

Infraestrutura as Code: Terraform, Ansible, CloudFormation.
Container Orchestration: Kubernetes, AKS, ECS.
Multi-Cloud: AWS, Azure, GCP.
Service Mesh: Istio.
Secrets Management: HashiCorp Vault, AWS Secrets Manager.

Continuous Deployment (CD)

Deploy nos ambientes provisionados.

Staging Deployment: é um ambiente de pré produção que replica um ambiente de produção. Nele você poderá fazer:
- Smoke test: verifica se os recursos críticos de um aplicativo funcionam corretamente.
- E2E testing: simula cenários reais de uso da aplicação, garante compatibilidade entre diferentes navegadores. Valida API.
- Performance testing: você pode usar uma ferramenta chamada Lighthouse para fazer isso, com ela você pode fazer validações de fluxo completo da aplicação, testes de acessibilidade, verificação da performance do site.
- Security testing: você pode usar o OWASP para fazer verificações de vulnerabilidades na sua página web, testes de penetração, DAST, etc.
Production Deploy: utilização de estratégias de deploy em produção.
- Blue-Green Deployment: Dois ambientes idênticos, switch instantâneo.
- Canary Deployment: Release gradual para subset de usuários.
- Rolling Deployment: Atualização incremental de instâncias.
- Feature flags: Controle de features sem redeploy.
- Health checks: Validação automática pós-deployment.
Rollback Strategy: mecanismo de reversão em caso de problemas:
- Automated rollback: Triggers baseados em métricas (error rate, latency)
- Health monitoring: Monitoramento contínuo pós-deployment
- Database migrations: Estratégias de rollback para mudanças de schema
- Traffic routing: Redirecionamento rápido para versão anterior
- Incident response: Procedimentos documentados para rollback manual

Observability & Monitoring

Monitoramento da aplicação em produção ou até mesmo em outros ambientes. E aqui existem várias ferramentas que podem te ajudar com isso:

Metrics: Prometheus, Opentelemetry, Grafana.
Trace: Jaeger, Zipikin, Opentelemetry, Hélios.
Logs: ELK stack, Fluentd.
APM: Site24×7, Dynatrace, Datadog.

Quanto tempo deve durar uma pipeline?

Isso também não é uma regra fixa - depende de vários fatores como tasks executando em paralelo, configuração de hardware do runner, tamanho do projeto, quantidade de testes, etc. Mas se precisássemos estabelecer um padrão aceitável, seria algo entre 5 a 15 minutos. Claro que existem casos que podem ultrapassar muito esse tempo.

Observações finais

Acredito que estes são os principais passos para ter uma pipeline moderna e performática. Várias etapas podem ser modificadas - testes podem rodar antes ou depois dos deploys, por exemplo.

É importante reforçar que nem todos os itens são necessários na sua pipeline, e nem precisam seguir exatamente essa ordem. Mas considero esta uma maneira simples e resumida de entender o que fazer do início ao fim de uma pipeline.

Arquitetura de uma pipeline