DevOps/DevSecOps: CALMS, shift-left, CI/CD, blue-green × canary × rolling, feature flags

A ideia que organiza o assunto

Desenvolvimento é medido por mudança; operação é medida por estabilidade. Como toda mudança ameaça a estabilidade, o incentivo de um time é atrasar o que o outro produz — e o ciclo que nasce daí é conhecido: entregar é caro, então acumula-se um lote grande; lote grande é arriscado, então cerca-se de aprovações; com mais aprovações, entrega-se menos vezes ainda. Do lado do código o mesmo acúmulo tem nome próprio, integration hell: cada um some no seu ramo por semanas e, quando todos voltam ao tronco, ninguém sabe qual das vinte mudanças quebrou o sistema.

DevOps responde a esse ciclo com uma inversão contraintuitiva, e é ela que organiza o assunto inteiro: entregar com mais frequência para arriscar menos. Lote pequeno tem superfície de erro pequena, causa localizável e caminho de volta barato. Para entregar com frequência, entregar precisa ser automático — daí o pipeline. Para que o pipeline seja confiável, o teste precisa vir antes e não depois — daí shift-left. E para que as duas equipes queiram a mesma coisa, a responsabilidade precisa ser compartilhada — daí a parte cultural, que o acrônimo CALMS resume: Culture, Automation, Lean, Measurement, Sharing.

Guardado o fracionamento do lote, o resto encaixa: integração contínua, entrega contínua e implantação contínua são apenas três estágios de quão longe a automação leva esse lote pequeno.

Por que se usa (e o que custa)

Ganha-se o que a pesquisa DORA mede com quatro indicadores: frequência de implantação, lead time da mudança, taxa de falha da mudança e MTTR — o tempo médio para restaurar o serviço. Os dois primeiros dizem quão rápido você anda; os dois últimos, quão seguro é andar rápido. O achado que sustenta o modelo é que eles não se opõem. O MTTR cai porque automação, monitoramento contínuo e realimentação rápida encurtam as três etapas de um incidente: perceber, diagnosticar e desfazer.

Paga-se em três lugares. O pipeline só vale o que valem seus testes, e manter essa bateria é trabalho permanente. Infraestrutura como código muda a complexidade de lugar — da máquina para o repositório — sem eliminá-la. E a parte mais cara é cultural: nenhuma ferramenta produz responsabilidade compartilhada onde o pós-incidente serve para escolher um culpado.

A formulação honesta para a prova: DevOps não elimina o risco da mudança, ele o fraciona. Troca poucas entregas grandes e perigosas por muitas entregas pequenas e reversíveis, e paga isso em automação, teste e telemetria.

Como funciona

As três “contínuas” formam uma escada. A integração contínua é uma disciplina antes de ser uma ferramenta: repositório único, build automatizado, build que se autotesta, todo mundo integrando ao tronco pelo menos uma vez por dia, cada integração disparando um build numa máquina de integração, build quebrado como prioridade número um e testes rodando num clone do ambiente de produção. O ciclo do desenvolvedor, que a banca já cobrou por escrito: testa localmente, atualiza o local a partir do repositório central, testa localmente de novo e só então atualiza o central.

A entrega contínua mantém o artefato permanentemente em estado liberável. O que fica manual nela é a decisão de liberar, que é de negócio — não a mecânica de liberar. Por isso duas frases que parecem opostas são ambas verdadeiras: a ida a produção depende de aprovação humana, e ainda assim a entrega contínua é uma prática de automação. A implantação contínua remove esse botão: o que passa no pipeline chega ao cliente sozinho.

O pipeline é uma sequência de portões. O artefato avança só se o estágio anterior passou: build (resolver dependências, compilar, vincular bibliotecas, empacotar), teste (unidade, integração, aceitação, segurança), guarda num repositório de artefatos e implantação nos ambientes — teste, homologação, produção. Quem executa isso: Jenkins (projeto Freestyle é configurado por etapas de build e ações pós-build; pipeline descrito em código é outro tipo de projeto), GitLab CI/CD (.gitlab-ci.yml com stages, jobs, variáveis e regras, executados por um runner), GitHub Actions (workflows e ações prontas, como actions/checkout). Ansible não está nessa lista: é gerenciamento de configuração e infraestrutura como código, escrito em Python e descrito em YAML.

Implantar é uma escolha, não um ato. No rolling, as réplicas são substituídas em lotes e as duas versões coexistem durante o processo. No blue-green, dois ambientes completos convivem e o tráfego é trocado de uma vez. No canary, a versão nova recebe uma fatia pequena do tráfego real e a fatia cresce conforme a métrica manda — é o único dos três que usa medição de produção como critério de avanço. Já as feature flags ficam num plano diferente: separam implantar de liberar. O código vai a produção desligado e é ativado depois, por configuração, o que dá kill switch sem novo deploy e cobra em troca a dívida das bandeiras esquecidas.

Shift-left é puxar para o começo o que ficava no fim. O argumento é econômico: o custo de corrigir um defeito cresce de ordem de grandeza a cada fase que ele atravessa. Daí a integração contínua estimular o teste antecipado com análise estática junto do código, e daí o princípio de monitorar e validar a qualidade operacional já no início do ciclo de vida. DevSecOps é o shift-left aplicado à segurança: controles automatizados dentro do pipeline — SAST (estático, sobre o código, cedo), DAST (dinâmico, contra a aplicação em execução, tipicamente orientado pelo OWASP) e SCA (dependências de terceiros, a frente que cobre a cadeia de fornecimento). Segurança integrada e distribuída, no lugar de um perímetro em torno da aplicação.

O que decide os itens

A escada das três contínuas — a distinção que decide a maior fatia do tópico:

	o que automatiza	onde termina	quem manda a produção
Integração contínua (CI)	compilar e testar a cada alteração enviada	artefato validado no repositório	não se aplica
Entrega contínua (delivery)	o da CI, mais empacotar e promover pelos ambientes	artefato pronto, sempre liberável	uma pessoa, apertando o botão
Implantação contínua (deployment)	o da entrega, mais o passo final	em produção, disponível ao cliente	ninguém: passou, subiu

Estratégias de implantação — o que cada uma compra e o que paga:

	o que convive	infraestrutura extra	volta atrás
Rolling	duas versões, lote a lote	nenhuma	lenta: outro rollout, ao contrário
Blue-green	dois ambientes; o tráfego troca de uma vez	dobrada na transição	imediata: redireciona o tráfego
Canary	uma fatia do tráfego, que cresce por métrica	pequena	rápida: remove a fatia

Quem faz o quê entre as ferramentas:

	faz	não faz
Jenkins / GitLab CI / GitHub Actions	orquestram build, teste e deploy	não versionam código
Runner do GitLab	executa os jobs do pipeline	não versiona o código-fonte — isso é o Git
Ansible	gerenciamento de configuração, IaC	não é ferramenta de integração contínua
Repositório de artefatos	guarda o que a CI produziu e serve para a implantação	não compila

Fronteiras que a banca repete: teste em clone do ambiente de produção, nunca no ambiente de produção; monitoramento é responsabilidade compartilhada, não privativa da operação; conteinerização combina com DevOps mas não é requisito dele; DevSecOps acrescenta segurança ao pipeline e não substitui a integração contínua; CI/CD vivem em construir, testar, liberar e implantar — não na etapa operate.

A ordem do ciclo de vida: planejar, codificar, construir, testar, liberar, implantar, operar, monitorar.

Números que caem

São poucos, e quase todos são cadência — que é exatamente onde a banca mexe.

integração ao tronco	pelo menos uma vez por dia, por desenvolvedor (nunca semanal)
build quebrado	prioridade número um, antes de qualquer funcionalidade nova
ciclo de liberação sob entrega contínua	dias ou horas — “mensal” ou “anual” é sempre erro
métricas DORA	4: frequência de implantação, lead time, taxa de falha da mudança, MTTR
CALMS	5 pilares: cultura, automação, lean, medição, compartilhamento
fases do ciclo de vida	8: planejar, codificar, construir, testar, liberar, implantar, operar, monitorar

Como a CEBRASPE derruba você aqui

Inversão — mais de um terço dos itens errados, e o gatilho quase sempre é a palavra “manual”. O tópico inteiro se organiza em torno de automatizar o que era manual, e a banca simplesmente desfaz isso: “implantar novas funcionalidades manualmente após a realização de muitos testes de regressão”; “monitoramento manual pausado”, onde o correto é contínuo e automatizado; “teste manual no final do desenvolvimento”, que é o oposto do shift-left; “evitar automatizar barreiras de segurança”. O segundo formato suprime uma etapa que a esteira não dispensa: um fluxo “na qual se prescinde a fase de teste”; uma entrega contínua que “não abrange a compilação e o teste”; a integração contínua que “não possibilita a realização de testes automatizados de aceitação”; “no processo de DevSecOps não há integração contínua, em vez dela” outra coisa — DevSecOps soma segurança à CI, não a substitui. O terceiro troca as metades de CI e CD: “a primeira realiza a implantação automática no repositório da solução após o build”, com a entrega contínua no lugar da integração; o Jenkins que “está mais relacionada à etapa monitor que à etapa deploy”; e a entrega contínua descrita como causa de “aumento do tempo entre os deploys”, quando ela reduz o intervalo. Antes de julgar, diga em voz alta qual é a propriedade essencial da prática. Se o item afirma o contrário dela — manual, ausente, mais lenta —, pare de ler.

Troca de termo — quase um terço, e a fronteira é sempre entre entrega e implantação. A frase descreve corretamente um conceito e assina o nome do vizinho: a entrega contínua que “exige que toda alteração no código seja automaticamente implantada em produção sem intervenção humana” — essa é a implantação contínua, e a diferença entre as duas é exatamente onde fica o botão humano; “CI refere-se à liberação automática” em produção, quando a CI termina no artefato validado; “A prática de CD tem como foco o uso de testes de unidade”, que é o foco da CI; “O processo de entrega contínua” recebendo a definição de integração frequente em repositório compartilhado; “a entrega contínua, que permite realizar tarefas repetitivas de maneira eficiente e confiável”, que é a definição de automação. O molde se repete fora do par CI/CD: “são os princípios básicos do DevOps” para o que define DevSecOps; um projeto Freestyle do Jenkins descrito com “o pipeline de compilação, o teste e a implantação”; o contêiner que “opera com um sistema operacional completo e independente”, que é a máquina virtual; “realizar o teste dos builds no ambiente de produção no qual o sistema final será executado”, quando se testa em clone; a master do gitflow chamada de “feature”; e o Ansible “escrita em Java e que usa JSON”, quando é Python e YAML. Leia a definição inteira, decida sozinho de que conceito ela é e só então olhe o nome que o item usou.

Generalização. Necessariamente, privativa, único, imediatamente: o DevOps que “requer necessariamente a utilização da prática de conteinerização”; o monitoramento “de responsabilidade privativa” da operação, quando é compartilhada; o build que resulta “em um único arquivo binário”, quando pode produzir vários artefatos; “implantar imediatamente as versões desenvolvidas no ambiente de produção”, sem os estágios de promoção. Cai aqui também a leitura errada da configuração: a pipeline só será criada “se as três regras de ativação do workflow.rules forem verdadeiras”, quando rules avalia em ordem e a primeira correspondência decide.

Número errado — sempre na cadência. Os três itens do tópico são o mesmo movimento: alongar o intervalo. Integrar “apenas uma vez por semana”; “no mínimo, um commit por semana”, quando o mínimo é diário; e “atualização anual” apresentada como vantagem da entrega contínua, que existe para encurtar o ciclo. Qualquer unidade de tempo maior que o dia, neste tópico, é suspeita.

Atribuição errada. Ação real, ator errado: “O Ansible é uma ferramenta de integração contínua”, quando é configuração e IaC; o runner encarregado do “versionamento automático do código-fonte de um repositório”, que é do Git; e CI/CD que “devem ser implementadas na etapa operar (operate)”, quando elas vêm antes dela no ciclo de vida.

Causa inventada. Um único item, mas o molde é reconhecível: o pipeline dispensa testes “uma vez que a gestão do código-fonte é iterativa”. A oração explicativa é o disfarce. Item que justifica suprimir teste, aprovação ou monitoramento é falso quase por construção.

Estratégias de implantação e CALMS — vocabulário ainda não medido. Nenhum dos itens explicados deste tópico menciona blue-green, canary, rolling ou CALMS pelo nome. As tabelas que a nota traz sobre eles continuam ali porque são vocabulário consagrado de DevOps e podem aparecer, mas não organize sua revisão em torno delas: o que a CEBRASPE cobra aqui, hoje, é a fronteira entre integração, entrega e implantação contínuas, e a cadência com que cada uma acontece.

Erros clássicos

Achar que “entrega contínua” significa entregar ao cliente. Ela deixa o software pronto para ser entregue, sempre. Quem entrega sem pedir licença é a implantação contínua.

Concluir daí que entrega contínua é manual. Manual é a decisão de publicar; a mecânica é automatizada. Descrever entrega contínua como implantação manual depois de testes manuais está errado — e exigir implantação automática em produção sem intervenção humana é descrever implantação contínua.

Testar “no ambiente de produção”. A prática manda testar num clone dele. A diferença é uma palavra e decide o item.

Supor que DevOps exige contêiner. Contêiner, Kubernetes e nuvem combinam com DevOps; nenhum deles é pré-requisito. DevOps é prática e cultura, a pilha é escolha.

Confundir blue-green com canary. Nos dois convivem versão nova e antiga, por motivos diferentes: no blue-green convivem ambientes, e o tráfego muda de uma vez; no canary convive tráfego, e a fatia cresce conforme a métrica. Quem troca tudo de uma vez não é canário.

Igualar o rollback das estratégias. No blue-green, voltar é redirecionar tráfego — segundos. No rolling, é outro rollout, lote a lote, no mesmo tempo do original.

Achar que DevSecOps freia o ciclo. Ele mantém o pipeline e automatiza os controles dentro dele, justamente para não voltar a ser um portão manual no fim.