{"id":155,"date":"2019-12-05T16:19:00","date_gmt":"2019-12-05T19:19:00","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2019\/12\/devops-ci-cd\/"},"modified":"2026-10-05T13:45:45","modified_gmt":"2026-10-05T16:45:45","slug":"devops-ci-cd","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2019\/12\/devops-ci-cd\/","title":{"rendered":"DevOps: \u00bfqu\u00e9 es CI\/CD?"},"content":{"rendered":"

\"Mascote<\/p>\n

Nota (2026):<\/strong> Texto original de dezembro de 2019 \u2014 gloss\u00e1rio de CI\/CD ainda no vocabul\u00e1rio Jenkins\/Red Hat, com a nota \u201cvai ser melhorado em breve\u201d. Sete anos depois o YAML no Git virou o padr\u00e3o (GitHub Actions, GitLab CI, Forgejo\/Gitea Actions), o CD em Kubernetes virou GitOps (Argo CD \/ Flux) e o pr\u00f3prio pipeline passou a ser alvo de ataque \u00e0 cadeia de suprimentos. O conceito n\u00e3o mudou; a ferramenta e a amea\u00e7a, sim. Revisado em 05\/10\/2026 com vers\u00f5es atuais e um diagrama do fluxo.<\/em><\/div>\n

CI\/CD n\u00e3o \u00e9 produto. \u00c9 o h\u00e1bito de integrar, testar e soltar software em ciclo curto<\/strong>, com o m\u00e1ximo de passos autom\u00e1ticos. O \u201cdia do merge\u201d de 2019 continua sendo o antipadr\u00e3o. O que mudou \u00e9 onde o YAML mora, quem roda o job e o que acontece depois<\/em> que o pipeline fica verde.<\/p>\n

<\/p>\n

CI, entrega e implanta\u00e7\u00e3o \u2014 os tr\u00eas CDs<\/h2>\n

CI (integra\u00e7\u00e3o cont\u00ednua):<\/strong> cada push ou merge request vira build e teste autom\u00e1ticos sobre o tronco compartilhado. O conflito aparece hoje, n\u00e3o na sexta-feira da release.<\/p>\n

Entrega cont\u00ednua:<\/strong> o artefato aprovado (bin\u00e1rio, imagem OCI, pacote) vai sozinho para um registro e fica pronto para produ\u00e7\u00e3o. A subida ainda depende de um humano no bot\u00e3o \u2014 ou de um crit\u00e9rio: tag, aprova\u00e7\u00e3o, janela de mudan\u00e7a.<\/p>\n

Implanta\u00e7\u00e3o cont\u00ednua:<\/strong> o mesmo artefato sobe sozinho para produ\u00e7\u00e3o se os testes passaram. O feedback do usu\u00e1rio chega em minutos. Exige testes em que voc\u00ea realmente confia, n\u00e3o um job verde oco.<\/p>\n

N\u00e3o vale brigar pelo acr\u00f4nimo. Vale desenhar o pipeline: o que \u00e9 autom\u00e1tico, o que \u00e9 porta e como se faz o rollback.<\/p>\n

\"Diagrama
O CI produz e assina o artefato; o CD leva o estado desejado do Git ao cluster; m\u00e9tricas e alertas devolvem o feedback.<\/figcaption><\/figure>\n

O pipeline em 2026: YAML no Git<\/h2>\n

Jenkins com plugins ainda roda muito legado. O ponto de partida no Linux hoje \u00e9 um arquivo no reposit\u00f3rio, um runner em container e o artefato em um registry.<\/p>\n

GitHub Actions<\/strong> \u2014 o padr\u00e3o de quem j\u00e1 est\u00e1 no GitHub. Fixe cada action pelo SHA do commit<\/em>, n\u00e3o por tag flutuante: em mar\u00e7o de 2025 as tags da action tj-actions\/changed-files<\/code> foram reapontadas para um commit malicioso que despejava secrets nos logs (CVE-2025-30066<\/a>). Quem usava @v45<\/code> rodou o c\u00f3digo do atacante; quem tinha fixado o SHA, n\u00e3o.<\/p>\n

# .github\/workflows\/ci.yml\nname: ci\non:\n  pull_request:\n  push:\n    branches: [main]\npermissions:\n  contents: read\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1\n      - run: make test\n<\/code><\/pre>\n
O bloco permissions<\/code> reduz o token do job ao m\u00ednimo necess\u00e1rio \u2014 sem ele, o padr\u00e3o pode ser mais amplo do que o teste precisa.<\/p>\n
GitLab CI<\/strong> \u2014 o que o post irm\u00e3o de 2019 j\u00e1 usava para Terraform. Um .gitlab-ci.yml<\/code> e runners pr\u00f3prios, se voc\u00ea quiser soberania:<\/p>\n
# .gitlab-ci.yml\nstages: [test, image]\n\ntest:\n  stage: test\n  image: golang:1.27\n  script:\n    - go test .\/...\n\nimage:\n  stage: image\n  image: docker:29\n  services: [docker:29-dind]\n  script:\n    - echo \"$CI_REGISTRY_PASSWORD\" | docker login -u \"$CI_REGISTRY_USER\" --password-stdin \"$CI_REGISTRY\"\n    - docker build -t \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\" .\n    - docker push \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n<\/code><\/pre>\n
As vari\u00e1veis CI_REGISTRY*<\/code> s\u00e3o preenchidas pelo pr\u00f3prio GitLab para o registry do projeto: nenhuma senha fica escrita no YAML.<\/p>\n
Forgejo Actions \/ Gitea Actions<\/strong> \u2014 sintaxe compat\u00edvel em boa parte com o GitHub Actions, rodando self-hosted, sem mandar o c\u00f3digo para a nuvem alheia. O passo a passo com runner est\u00e1 no post sobre o Gitea com Actions e runner<\/a>. O Woodpecker \u00e9 a outra op\u00e7\u00e3o leve. No homelab Linux, isso compete com o GitLab CE.<\/p>\n
O curso de Docker<\/a> continua sendo pr\u00e9-requisito: o job moderno \u00e9<\/em> um container. Infraestrutura como c\u00f3digo segue o mesmo esp\u00edrito: Ansible<\/a> e o pipeline de Terraform no GitLab<\/a>.<\/p>\n
CD virou GitOps<\/h2>\n
Implantar no Kubernetes em 2026 raramente \u00e9 kubectl apply<\/code> dentro do job de CI. O CI constr\u00f3i a imagem, assina, envia ao registry e atualiza o Git<\/em> (tag ou digest). O cluster puxa o estado desejado:<\/p>\n