Continuous Integration (CI)

A integração contínua (CI) é a prática de mesclar frequentemente as alterações de cada desenvolvedor em uma ramificação principal compartilhada, pelo menos diariamente, e compilar e testar cada alteração automaticamente, para que os problemas de integração apareçam em poucos minutos, em vez de só no lançamento. Grady Booch propôs o termo em 1991, Kent Beck tornou a prática central da Programação Extrema no fim da década de 1990, e o artigo de Martin Fowler Continuous Integration descreve o fluxo de trabalho que a maioria das equipes ainda segue. Em aprendizado de máquina (ML), a CI também verifica os dados, o código de treinamento e o comportamento do modelo, pois uma alteração pode manter todos os testes unitários aprovados e, ainda assim, reduzir a precisão do modelo.

Como funciona um pipeline de CI#

Quando um desenvolvedor envia uma ramificação ou abre uma solicitação de pull, um serviço de CI, como o GitHub Actions, o GitLab CI/CD ou o Jenkins, inicia um executor novo, obtém o código, instala as dependências e executa um pipeline de tarefas: linters e verificadores de tipos, testes unitários, testes de integração e compilações de pacotes ou imagens de contêiner. Cada tarefa informa seu status à solicitação de pull, e as regras de proteção da ramificação podem bloquear uma mesclagem até que todas as verificações obrigatórias sejam aprovadas. Os pipelines costumam repetir os mesmos testes em uma matriz de sistemas operacionais e versões do Python, além de executar novamente todo o conjunto de testes na ramificação principal após cada mesclagem. A velocidade faz parte da prática: a Programação Extrema de Beck definiu como meta dez minutos para compilar todo o sistema e executar todos os testes, pois uma compilação mais lenta é executada com menos frequência.

CI para aprendizado de máquina#

Projetos de ML acrescentam suas próprias verificações. Os testes de dados confirmam que os novos dados de treinamento correspondem ao esquema esperado, que todos os arquivos de rótulos podem ser analisados e que nenhuma imagem aparece tanto na partição de treinamento quanto na de validação, o que causaria vazamento de dados. Um teste rápido treina por uma época em um conjunto de dados minúsculo para detectar erros de formato e falhas em poucos minutos. Testes que comparam saídas do modelo fixam as sementes aleatórias e permitem pequenas tolerâncias numéricas, já que os kernels da GPU e a ordem de carregamento dos dados podem alterar os resultados de ponto flutuante entre execuções. Uma verificação de qualidade avalia o modelo em um conjunto de validação fixo e reprova a compilação se uma métrica, como a precisão média média (mAP), cair abaixo de um limite; testes de exportação verificam se as versões do modelo em ONNX ou TensorRT continuam carregando e obtendo pontuações como o original. O treinamento completo é lento e os executores com GPU são caros, então as equipes costumam executar verificações rápidas em cada solicitação de pull e deixar o retreinamento completo e a implantação do modelo para execuções agendadas ou na ramificação principal; ferramentas de versionamento como o DVC permitem que cada tarefa obtenha a versão exata do conjunto de dados necessária.

O modo de benchmark da Ultralytics YOLO funciona como essa verificação: quando verbose é definido como um número de ponto flutuante, como 0.216, ele gera um erro se uma exportação falhar ou se o mAP_50-95 de qualquer formato exportado não ultrapassar esse limite, e a própria CI do repositório Ultralytics o usa para testar exportações do YOLO26 em executores Linux, macOS e ARM. Um fluxo de trabalho mínimo do GitHub Actions combina testes unitários com essa verificação:

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Cada solicitação de pull e cada envio para main executa a tarefa em um executor Ubuntu novo. Um teste unitário que falha ou um modelo ONNX com pontuação igual ou inferior ao limite no pequeno conjunto de dados COCO8 deixa a verificação vermelha antes que a alteração possa ser mesclada.

CI, CD, MLOps e treinamento contínuo#

• Entrega contínua (CD): Mantém as compilações aprovadas pela CI prontas para lançamento, muitas vezes implantando-as automaticamente em um ambiente de preparação. A implantação contínua vai além e envia à produção todas as alterações aprovadas.
• MLOps: A disciplina mais ampla que combina CI e CD com versionamento de dados, implantação de modelos, monitoramento e retreinamento ao longo do ciclo de vida do ML.
• Treinamento contínuo (CT): Retreina e reimplanta um modelo automaticamente quando chegam novos dados ou o monitoramento detecta uma deriva. Os níveis de maturidade de MLOps do Google classificam o retreinamento automatizado como nível 1 e a CI/CD automatizada do próprio pipeline de treinamento como nível 2.