Linhas de montagem CI/CD: GitHub Action, GitLab CI

Linhas de montagem CI/CD: GitHub Action, GitLab CI

1) Tarefa CI/CD e espaço na plataforma

• Velocidade e previsibilidade de lançamentos (lead time curto).
• Qualidade (auto, análise estática/dinâmica).
• Segurança da cadeia de fornecimento (assinatura de artefatos, controle de acessibilidade).
• Confiabilidade (depósitos canários, reversão rápida).
• Observabilidade (traçado e métricas em cada etapa).

Princípios-chave: «pipeline as código», artefatos imutáveis, «build once - run many», «shift-left security», «least privege», montagens determinadas.

2) Roteiros arquitetônicos de linha de montagem

Stage-gate: build → test → security → package → deploy → post-deploy checks.
Fan-out/Fan-in: montagens de matriz paralelas (linguagens/plataformas) com combinação de resultados.
Promoção: O mesmo artefato avança através do ambiente (dave → estágio → prod) em vez de ser reconduzido.
Trunk-based + ramos curtos: minimização da deriva, verificações automatizadas em PR/MR.
Reusable: workflow/modelos reutilizados (Action: reusable workflows; GitLab: includes/child-pipelines).
GitOps (opcional): Separa «montagem» e «entrega» (Argo CD/Flux monitoram o repo declarado dos ambientes).

3) Segurança da cadeia de fornecimento (suply chain)

Identificação: Federação OIDC de runner 'a para nuvem (sem chaves de longa duração).
Segredos: armazenamento centralizado, limitação de contexto, proibição de saída no logs.
Assinatura de artefatos/contêineres (cosign/Sigstore), verificação de assinatura no controle de admissão.
SBOM (CycloneDX/SPDX) e SCA, SAST/DAST/Container Scan - «porta obrigatória».
Políticas: OPA/Conftest para IaC/manifestos, «no latest», proibição de contêineres privilegiados.
Isolar runner 'ov: prod runners em uma rede privada, separar da Internet pública acesso.

4) GitHub Action - estrutura e práticas

4. 1 Estrutura workflows

`.github/workflows/.yml` — триггеры (`on: push, pull_request, schedule, workflow_call`).
Reusable workflows para normalização (linter, SCA, montagem de contêineres, deplom).

4. 2 Exemplo: Pipeline multipremiado com OIDC e assinatura de imagem

yaml name: ci-cd

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

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh

• 'persissions' foram minimizados, incluído 'id-tocen: write' para OIDC.
• Ambientonments com approvers e URL, 'concurrency' protege contra corridas.
• Activação de canário de tráfego e reversão automática de SLO.

4. 3 Reusable workflow (exemplo de chamada)

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5) GitLab CI - estrutura e práticas

5. 1 Estrutura básica

`.gitlab-ci. yml 'na raiz; entidades-chave: «estágios», «jobs», «rulas», «needs',» artifacts', «ambientonments», «manual».
Reuse: 'inclusive:' (modelos locais/remote), child/parent pipelines para monorrepos complexos.

5. 2 Exemplo: matriz, dinheiro, assinatura, ambientes e approvals

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh

• `parallel. matrix 'simula montagens de matriz.
• 'artifacts' + relatórios de testes.
• Ambientonments s 'on _ stop', manuais 'when: manual' para approvals.
• DIND para montagem de imagem (melhor - Kaniko/BuildKit em k8s runner).

5. 3 Child pipelines e incluída para monorrepo

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6) Monorreposição e multi-capacidade

Diretory-based ownership: CODEOWNERS e testes de scoped via.
Incremental builds: identifique os pacotes/listas afetados; dinheiro em chave de caminho e arquivos lock.
Dinamic pipelines: child-pipelines/' workflow _ call' são executados apenas para componentes alterados.
Versioning: semver para cada módulo, changelog na fase release.

7) Em dinheiro e aceleração

Cachês de conteúdo (hashFiles/lockfile).
Dinheiro separado para dependências e artefactos.
Pre-warm runner images (toolchains, SDK).
Espelhos locais de pacotes (npm/pip/maven) e contêineres registry-kesh.

8) Estratégias de lançamento e retrocesso

Canary: aumento gradual da porcentagem de tráfego; auto-parada para degradação do SLO.
Blue-Green: pilhas paralelas, mudança instantânea.
Shadow: duplicação de solicitações sem afetar o cliente.
Função flags: rollout ao nível da bandeira, não do lançamento.
Rollback: Um botão nítido, a versão do artefato está armazenada nos metadados de lançamento.

9) Infraestrutura e GitOps

IaC: Terraform/Ansable/Helm são controlados em repos individuais; policy-as-código como um portão.
Circuito GitOps: Argo CD/Flux observam o repo com manifestos de ambientes; A linha de montagem apenas cria o artefato e atualiza as versões no Git.
Vantagens: histórico claro de alterações de ambiente, idempotidade, reversões padrão via Git.

10) Observabilidade CI/CD

Métricas DORA: frequência de deploes, tempo de comitiva, produção, taxa de rejeição, MTTR.
Telemetry: tempo de fila de job's, duração de estágios, hit-rate de cachê, frequência de testes flaky.
Logs de segurança: quem iniciou o lançamento, que portões foram ultrapassados, quais exceções foram emitidas.

11) Controle de acesso e approvals

O Branch Proteção e as verificações obrigatórias.
Ambientonment-approvals: listas individuais de approvers para o estágio/prod.
Acesso JIT para passos manuais, registro de sessões.
Separação de responsabilidades: diferentes papéis para «escreve código», «aprova», «solta».

12) Erros frequentes (anti-pattern)

Chaves de nuvem de longa duração em segredos de repo em vez de papéis OIDC.
Montagem de artefatos diferentes para estágio e prod (violação «build once»).
'latest' tags e imagens mutáveis.
Publicar segredos em logs de passos (masking sem chave).
Um público-runner compartilhado para prod-deploy.
Falta de «portões» de segurança (SAST/SCA/Policy) e verificações pós-deploy.

13) Folha de cheque de implementação (0-60 dias)

0-15 dias

Configure as regras trunk-based, PR/MR, verificações estáticas obrigatórias.
Incluir a Federação OIDC na nuvem; «Percussions» mínimos.
Distribuir runner's: público para CI, privado para CD.

16 a 30 dias

Adicionar SBOM, assinar imagens; no cluster - Verificação de assinatura.
Digite canary/blue-green; auto-rollback por SLO.
Cash dependências e artefactos, imagens pré-warm.

31 a 60 dias

Dividir montagem e entrega (GitOps), policy-as-código portões.
Arranjar métricas DORA e alertas de degradação de piplins.
Modelo de pipline (reusable/child) para todos os serviços.

14) Dicas práticas de confiabilidade

Mantenha pipinas pequenas e rápidas (10-12 min para sinal por PR).
Mate os testes flaky: quarantine rótulos + fix paralelo.
Não misture artefatos CI e release; armazenem os metadados (commit, tempo, SBOM, assinaturas).
Dê aos desenvolvedores um cenário local idêntico ao da linha de montagem.

15) Modelos de reutilização

15. 1 GitHub Action - segurança reusable workflow (simplificado)

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15. 2 GitLab - Modelo deploy incluído (simplificado)

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16) Conclusão

O Action e o CI fornecem mecanismos maduros para um ciclo rápido e seguro de código de proda. A chave para o sucesso é a normalização e segurança: OIDC em vez de chaves, assinatura e SBOM, portão de qualidade, um único artefato com promoção, entrega GitOps e observabilidade via DORA. Construa as pipas como um produto: mede, simplifique, acelere - e os lançamentos são uma rotina, não um evento.