{"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-09-08T10:05:34","modified_gmt":"2026-09-08T13:05:34","slug":"devops-ci-cd","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2019\/12\/devops-ci-cd\/","title":{"rendered":"DevOps, o que \u00e9 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 default (GitHub Actions, GitLab CI, Forgejo), o CD em Kubernetes virou GitOps (Argo CD \/ Flux), e o pr\u00f3prio pipeline passou a ser alvo de supply chain. Conceito n\u00e3o mudou; a ferramenta e a amea\u00e7a, sim.<\/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 passo autom\u00e1tico. O \u201cmerge day\u201d de 2019 continua sendo o anti-padr\u00e3o. O que mudou \u00e9 onde o YAML mora, quem roda o job e o que acontece depois<\/em> do verde no pipeline.<\/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\/MR vira build + teste autom\u00e1tico no tronco compartilhado. O conflito aparece hoje, n\u00e3o na sexta da release.<\/p>\n

Entrega cont\u00ednua:<\/strong> o artefato aprovado (bin\u00e1rio, imagem OCI, pacote) vai sozinho para um registro. Produ\u00e7\u00e3o ainda tem um humano no bot\u00e3o \u2014 ou um crit\u00e9rio (tag, aprova\u00e7\u00e3o, janela).<\/p>\n

Implanta\u00e7\u00e3o cont\u00ednua:<\/strong> o mesmo artefato sobe sozinho para produ\u00e7\u00e3o se o teste passou. Feedback do usu\u00e1rio em minutos. Exige teste 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, o que \u00e9 rollback.<\/p>\n

commit \u2192 CI (lint, test, build)\n       \u2192 artefato no registry (entrega)\n       \u2192 staging\n       \u2192 produ\u00e7\u00e3o (implanta\u00e7\u00e3o: bot\u00e3o ou autom\u00e1tica)\n       \u2192 observa\u00e7\u00e3o (m\u00e9trica, log, alerta)\n<\/code><\/pre>\n
O pipeline em 2026: YAML no Git<\/h2>\n
Jenkins com plugin ainda existe em legado. O ponto de partida no Linux hoje \u00e9 um arquivo no reposit\u00f3rio, runner em container, artefato em registry.<\/p>\n
GitHub Actions<\/strong> \u2014 o default de quem j\u00e1 est\u00e1 no GitHub. Pin de action por SHA, n\u00e3o por tag flutuante: o CI virou vetor (compromisso de actions populares em 2025\u20132026).<\/p>\n
# .github\/workflows\/ci.yml\nname: ci\non:\n  pull_request:\n  push:\n    branches: [main]\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v4\n      - run: make test\n<\/code><\/pre>\n
GitLab CI<\/strong> \u2014 o que o post irm\u00e3o de 2019 j\u00e1 apontava para Terraform. Um .gitlab-ci.yml<\/code>, runners pr\u00f3prios se quiser soberania:<\/p>\n
# .gitlab-ci.yml\nstages: [test, image]\ntest:\n  stage: test\n  image: golang:1.24\n  script: [go test .\/...]\nimage:\n  stage: image\n  image: docker:27\n  services: [docker:27-dind]\n  script:\n    - docker build -t registry.example.com\/app:$CI_COMMIT_SHA .\n    - docker push registry.example.com\/app:$CI_COMMIT_SHA\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n<\/code><\/pre>\n
Forgejo Actions \/ Gitea<\/strong> \u2014 o mesmo YAML do Actions, self-hosted, sem mandar o c\u00f3digo para a nuvem alheia. Woodpecker \u00e9 o outro bin\u00e1rio leve. No homelab Linux isso compete com GitLab CE.<\/p>\n
O curso de Docker<\/a> continua sendo o pr\u00e9-requisito: o job moderno \u00e9<\/em> um container. Infra como c\u00f3digo no 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> no job de CI. O CI constr\u00f3i a imagem, assina, empurra o registry e atualiza o Git<\/em> (tag, digest). O cluster puxa o estado desejado:<\/p>\n