Youtube Video: https://www.youtube.com/watch?v=A_kuxQAgNv4&t=111s
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.
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.
