Organize o fluxo entre GitHub e Jenkins

Use pull requests no GitHub para revisão e checks obrigatórios, e integre o Jenkins por webhook ou mecanismo aprovado pela organização. Separe permissões de leitura do repositório, publicação de imagens e implantação: um build de pull request não confiável não deve receber credenciais de produção. Restrinja branches e ambientes de deploy segundo as regras do time.

Guarde o Jenkinsfile junto ao código para versionar o processo. Fixe versões de plugins e ferramentas onde possível, use agentes isolados e preserve logs de build sem imprimir segredos.

Valide e construa um artefato reproduzível

Uma sequência comum restaura dependências, compila, executa testes, verifica qualidade e só então constrói a imagem. Use tags imutáveis ligadas ao commit e, depois da publicação, promova a mesma imagem entre ambientes em vez de recompilar conteúdo diferente. Associe artefatos, dependências e resultados de testes à revisão de origem.

pipeline {
  agent any
  stages {
    stage('Validar') {
      steps {
        sh 'dotnet restore'
        sh 'dotnet build --configuration Release --no-restore'
        sh 'dotnet test --configuration Release --no-build'
      }
    }
    stage('Publicar imagem') {
      when { branch 'main' }
      steps {
        script {
          docker.withRegistry('https://registry.example.com',
                              'registry-credentials') {
            def imagem = docker.build(
              "wholly/pedidos:${env.GIT_COMMIT}")
            imagem.push()
          }
        }
      }
    }
  }
}

Esse exemplo depende do plugin Docker Pipeline, de agente com Docker e de uma credencial configurada no Jenkins. Não coloque tokens no Jenkinsfile. Ajuste solução, projetos e regras de branch; retenha a referência do commit e prefira também registrar o digest da imagem publicado.

Trate Docker como artefato, não como ambiente

Use imagem multi-stage, usuário sem privilégios quando suportado, build context restrito e configuração por ambiente. Não inclua segredos em camadas, argumentos, variáveis de build ou repositório. Para construir a imagem, veja Docker para .NET. Faça scan de dependências e imagens conforme a política do projeto.

Configure manifests Kubernetes para operação

Um Deployment controla réplicas e rollout; um Service fornece descoberta dentro do cluster. Defina probes adequadas, limites de recursos e configuração externa à imagem. Readiness controla quando uma instância pode receber tráfego; liveness detecta um processo que precisa reiniciar. Não use uma verificação de liveness que reinicie a aplicação apenas porque um serviço externo está temporariamente indisponível.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pedidos
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pedidos
  template:
    metadata:
      labels:
        app: pedidos
    spec:
      containers:
        - name: api
          image: registry.example.com/wholly/pedidos:COMMIT_SHA
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 512Mi

Substitua placeholders, valide probes e recursos com a aplicação real e mantenha manifests específicos por ambiente ou templates revisáveis. Não armazene credenciais em texto simples no Git; use o mecanismo de secrets aprovado e controles de acesso mínimos.

Implante com rollout, verificação e rollback

Após aprovar o artefato, atualize a referência de imagem e aplique manifests por meio de identidade de implantação com escopo mínimo. Aguarde o rollout, verifique readiness, erros e latência e interrompa a promoção se os critérios não forem atendidos. Tenha rollback para uma versão conhecida, migrações compatíveis com versões simultâneas e estratégia para evitar que uma mudança de banco impeça a reversão da aplicação.

Para diagnosticar uma regressão após deploy, relacione commit e versão do artefato aos traces, logs e métricas no Dynatrace. Inclua testes de carga controlados com k6 quando a mudança afetar capacidade ou latência.

Documentação e leituras relacionadas