Reconciliando a implantação contínua com políticas rígidas de gerenciamento de alterações

Estou curioso para saber como outras pessoas arquitetam suas práticas de DevOps em um ambiente estrito de gerenciamento de mudanças, como no processo de aprovação de um conselho consultivo de mudanças (CAB) .

Entendo que a automação pode melhorar seu processo de auditoria, garantindo um processo mais rigoroso, comprovável e repetível. Mas parece que a implantação contínua é mais ou menos impossível em tal situação. Como pode levar uma semana ou mais para que as alterações sejam aprovadas, você perde a capacidade de implantar com rapidez e frequência. Quais etapas você adota para trabalhar nesses processos, apenas enviando solicitações de mudança e aguardando aprovação?

Se você deve aderir ao processo de mudança, ficará limitado de acordo com as limitações do processo de mudança, ponto final. Se as alterações precisarem ser aprovadas antes da implantação, você não poderá fazer a implantação contínua. Se a aprovação demorar muito, você não poderá implantar rapidamente. Não há solução alternativa para você seguir o processo e não ser impactado por ele. Esse é o custo de acompanhar o processo de mudança e vale a pena chamar a atenção das partes interessadas nesse processo.

Nem tudo está perdido ... você pode maximizar a automação em todo o processo, a fim de minimizar erros; todas as etapas do CD, exceto a ligação entre gerar um artefato estável e implantar esse artefato na produção. Essa ligação seria substituída por algum tipo de intervenção do usuário (botão, comando da CLI etc.) ou vinculada ao registro de aprovação (por exemplo, quando um ticket de solicitação de mudança for movido para o estado "aprovado", ative a implantação associada ) Você só precisa extrair o máximo de benefícios possível, enquanto segue o processo obrigatório com o qual se deparou. Isso não fará com que as aprovações sejam mais rápidas, é claro.