04 · Pipelines como produto

Os times escrevem só o que é específico da aplicação; build, scans, publicação e deploy vêm de templates versionados do projeto platform.

Mecanismo de imposição

• Pipelines de aplicação usam extends para um template do platform, referenciado por tag (ref: refs/tags/v3).
• Required template check em Environments, service connections e agent pools de produção: um pipeline que não estende o template aprovado não consegue fazer o deploy.
• Classic pipelines desabilitados na organização; somente YAML.
• Parâmetros tipados no template expõem o que o time pode escolher (linguagem, testes extras) e escondem o que não pode (scans, assinatura).

# azure-pipelines.yml de uma aplicação
resources:
  repositories:
    - repository: templates
      type: git
      name: platform/pipeline-templates
      ref: refs/tags/v3

extends:
  template: java/servico.yml@templates
  parameters:
    jdk: 17
    testesIntegracao: true

Build pipeline (CI)

1. Restore com feeds internos (sem acesso direto à internet).
2. Compilação e testes unitários com cobertura.
3. SAST, SCA, secret scanning e IaC scanning.
4. Geração de SBOM e de provenance.
5. Publicação do artefato imutável, versionado e assinado.

Deployment pipeline (CD)

• Deployment jobs apontando para Environments, consumindo o artefato do CI pelo ID do run.
• Configuração por ambiente injetada no deploy (variable groups ligados ao Key Vault), nunca recompilada.
• Smoke test após cada deploy e verificação de saúde antes de promover.

Quality gates

Artifact repository

• Azure Artifacts para pacotes (Maven, npm), com upstream sources e views @prerelease / @release para promoção.
• Registry de imagens com retenção e bloqueio de tag mutável em produção.

Indicadores: D3 · Pipelines como produto