https://itpartners.com.br/assets/ContinuousDeploymentPage-DrFNUF7y.js

1import{d as n,j as e}from"./index-DLjM3o88.js";import{B as s,S as a,H as o,I as i,a as r,R as d}from"./BlogArticleLayout-Do2XrwDW.js";import{b as t}from"./blog-continuous-deployment-CM0gK5dn.js";import"./Footer-DdbLSzit.js";import"./arrow-up-right-D7FY9ai3.js";import"./phone-n4B2MeQG.js";import"./mail-DMJurrH9.js";import"./map-pin-BomDQQY2.js";import"./share-2-BNw2f8L-.js";import"./link-2-B4-HNdDO.js";import"./quote-68kEKUzw.js";import"./brain-CnkTn0z_.js";import"./circle-check-BHoizIq2.js";import"./circle-x-C9jrklS7.js";import"./arrow-left-DhOQaqwZ.js";import"./textarea-B6UiB0qx.js";import"./star-DJh2O1bd.js";/**
2 * @license lucide-react v0.462.0 - ISC
3 *
4 * This source code is licensed under the ISC license.
5 * See the LICENSE file in the root directory of this source tree.
6 */const m=n("GitBranch",[["line",{x1:"6",x2:"6",y1:"3",y2:"15",key:"17qcm7"}],["circle",{cx:"18",cy:"6",r:"3",key:"1h7g24"}],["circle",{cx:"6",cy:"18",r:"3",key:"fqmcym"}],["path",{d:"M18 9a9 9 0 0 1-9 9",key:"n2h4wq"}]]),l="/assets/blog-inline-pipeline-CqE0A4Dw.jpg",c="/assets/blog-inline-deploy-flow-DWmHRG66.jpg",B=()=>e.jsxs(s,{category:"ITIL®",date:"23/08/2026",readTime:"10 min de leitura",title:"O Guia Definitivo para o Gerente de Mudanças",highlightTitle:"na Era do Continuous Deployment",subtitle:"Quando mudanças deixam de ser eventos e passam a ser fluxo contínuo, o controle não desaparece — ele migra do ato de aprovar para o ato de projetar confiabilidade.",heroImage:t,children:[e.jsxs(a,{title:"O modelo que funcionava — e por que parou de funcionar",children:[e.jsx("p",{children:"Durante anos, o gerenciamento de mudanças foi sustentado por uma premissa silenciosa: mudanças são eventos discretos, planejáveis e relativamente raros. Sob essa lógica, comitês (CABs), janelas de manutenção e aprovações em camadas faziam todo o sentido. O modelo era proporcional ao ritmo do negócio."}),e.jsx("p",{children:"Esse mundo deixou de existir em organizações que adotaram entrega contínua. Quando deploys passam de mensais para diários — e em alguns casos para múltiplos por hora — o modelo de aprovação caso a caso vira gargalo, vira teatro de governança ou simplesmente é contornado. Em qualquer dos cenários, o resultado é o mesmo: o controle real evapora."}),e.jsx(o,{children:"Aprovar manualmente uma mudança em um pipeline contínuo é como pedir autorização individual para cada passo de uma escada rolante. O modelo precisa mudar — e essa mudança é responsabilidade do gerente de mudanças."})]}),e.jsx(i,{src:l,alt:"Pipeline de continuous deployment com automação",caption:"O pipeline contínuo é o novo locus de governança — não a sala do CAB."}),e.jsxs(a,{title:"O reposicionamento: de controlador a arquiteto",children:[e.jsx("p",{children:'O ITIL 4 já sinalizava essa mudança ao reformular a prática de Change Enablement. O ponto central é simples: o papel do gerente de mudanças deixa de ser "permitir ou bloquear" cada alteração e passa a ser "garantir que o sistema, como um todo, comporta mudanças contínuas com segurança". É uma mudança de função, não de título.'}),e.jsx(r,{icon:m,title:"A nova mesa de trabalho",children:"Critérios de aceitação automatizados, gates de qualidade, observabilidade, rollback automático, feature flags e progressive delivery passam a ser os instrumentos do gerente de mudanças moderno."}),e.jsx("p",{children:"O gerente de mudanças maduro nesse novo cenário entende de pipeline, de risco distribuído e de SRE — não no nível de implementação, mas no nível de desenho de garantia. Ele se torna o arquiteto da confiabilidade do fluxo de mudanças, não o auditor de cada uma delas."})]}),e.jsx(a,{title:"O que substitui o CAB no modelo contínuo",children:e.jsxs("p",{children:["O CAB tradicional não desaparece — ele se especializa. Em vez de discutir cada mudança, passa a discutir ",e.jsx("strong",{children:"classes de mudança"}),": definir, em conjunto, quais alterações podem ser totalmente automatizadas (Standard), quais exigem revisão técnica leve (Normal de baixo risco) e quais precisam de governança humana real (Emergencial e de alto risco). Esse desenho é, em si, o principal artefato de governança do gerente de mudanças moderno."]})}),e.jsx(i,{src:c,alt:"Fluxo paralelo de deploys automatizados em produção",caption:"O controle migra do checkpoint para o desenho: cada gate automatizado é, hoje, uma decisão de governança."}),e.jsxs(a,{title:"A maturidade emocional da nova função",children:[e.jsx("p",{children:"Há um aspecto pouco discutido nessa transição: o desconforto. Aceitar que não se vai mais aprovar individualmente cada mudança exige uma maturidade que vai além do técnico. Exige confiar em um sistema bem desenhado mais do que em um carimbo individual. Esse é, talvez, o maior obstáculo cultural à modernização da gestão de mudanças."}

6),e.jsx(o,{children:"O controle absoluto sempre foi uma ilusão confortável. O modelo contínuo apenas torna essa ilusão impossível de sustentar — e isso é, paradoxalmente, uma boa notícia."})]}),e.jsx(a,{title:"O que separa as organizações maduras das demais",children:e.jsxs("p",{children:["Em mais de duas décadas observando equipes de change enablement, há um padrão claro nas organizações que operam bem em alta velocidade: elas tratam ",e.jsx("strong",{children:"confiabilidade como um produto interno"}),". Têm donos, têm roadmap, têm métricas próprias e têm investimento dedicado. Não é tarefa colateral de quem opera incidente — é disciplina autônoma. Onde isso existe, a velocidade não compromete o controle. Onde não existe, a velocidade é apenas dívida acelerada."]})}),e.jsx(d,{children:'A pergunta não é mais "devemos mudar?". É "como mudar continuamente sem comprometer o todo — e quem, na sua organização, é o arquiteto dessa garantia?".'})]});export{B as default};