Pular para conteúdo

Pipelines CI/CD

A InteSys projeta e implementa pipelines CI/CD que automatizam seu fluxo de trabalho de build, teste e implantação. Somos especialistas em GitLab CI e GitHub Actions, mas oferecemos suporte a qualquer plataforma CI/CD principal.

Princípios de Design de Pipeline

Um pipeline bem projetado deve ser:

  • Rápido — Estágios paralelos, cache e builds incrementais minimizam o tempo de feedback
  • Confiável — Builds determinísticos com dependências fixadas e ambientes reproduzíveis
  • Seguro — Segredos gerenciados externamente, imagens verificadas e execução com privilégio mínimo
  • Observável — Logs claros, artefatos e notificações de status

GitLab CI

O GitLab CI é nossa plataforma recomendada para equipes que usam repositórios self-hosted ou GitLab SaaS.

Exemplo de Pipeline

stages:
  - test
  - build
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: "/certs"

test:
  stage: test
  image: python:3.12-slim
  script:
    - pip install -r requirements.txt
    - pytest tests/ --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
  only:
    - main

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  environment:
    name: production
  only:
    - main
  when: manual

Principais Recursos do GitLab CI

  • Docker-in-Docker — Construa imagens de contêiner dentro de jobs CI
  • Artefatos e cache — Compartilhe arquivos entre estágios e acelere builds
  • Ambientes — Rastreie implantações por ambiente com suporte a rollback
  • Variáveis protegidas — Armazene segredos com segurança com acesso por escopo de ambiente
  • Review apps — Crie ambientes temporários para revisão de merge requests

GitHub Actions

Para equipes no GitHub, construímos workflows usando GitHub Actions com componentes reutilizáveis.

Exemplo de Workflow

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Testes Automatizados em Pipelines

Tipo de Teste Estágio Objetivo
Testes unitários test Validar funções e métodos individuais
Testes de integração test Verificar interações entre componentes
Linting test Aplicar estilo de código e detectar erros comuns
SAST test Análise estática de segurança
Verificação de contêiner build Detectar vulnerabilidades em imagens Docker
Smoke tests deploy Verificar a saúde da implantação após o release

Falhe Rápido

Execute os testes mais rápidos primeiro (linting, testes unitários) para que os desenvolvedores recebam feedback rápido. Mova testes mais lentos (integração, verificações de segurança) para estágios posteriores.

Estratégias de Implantação

Implantação Blue-Green

Mantenha dois ambientes idênticos. Implante no inativo, verifique e então redirecione o tráfego.

  • Zero downtime — O tráfego é redirecionado instantaneamente
  • Rollback fácil — Volte para o ambiente anterior
  • Custo — Requer o dobro de infraestrutura durante a implantação

Implantação Canary

Direcione gradualmente uma porcentagem do tráfego para a nova versão.

  • Redução de risco — Problemas afetam apenas uma pequena porcentagem dos usuários
  • Baseada em métricas — Promova ou faça rollback com base em taxas de erro e latência
  • Complexidade — Requer divisão de tráfego (Istio, Nginx ou load balancer na nuvem)

Rolling Update

Substitua instâncias uma por vez (padrão do Kubernetes).

  • Eficiente em recursos — Sem infraestrutura extra necessária
  • Gradual — Versões antiga e nova rodam simultaneamente durante a implantação
  • Rollback — O Kubernetes faz rollback automaticamente em caso de falha nos health checks

Próximos Passos