CAB (변경 자문위원회) 승인 프로세스 와 같은 엄격한 변경 관리 환경에서 다른 사람들이 DevOps 사례를 어떻게 설계하는지 궁금합니다 .
자동화는보다 엄격하고 입증 가능하며 반복 가능한 프로세스를 보장함으로써 감사 프로세스를 향상시킬 수 있음을 이해합니다. 그러나 그러한 상황에서는 지속적인 배포가 다소 불가능한 것 같습니다. 변경 사항을 승인하는 데 1 주일 이상이 걸릴 수 있으므로 신속하고 자주 배포하는 기능이 손실됩니다. 변경 요청을 제출하고 승인을 기다리는 것 외에는 이러한 프로세스에서 어떤 단계를 수행해야합니까?
답변:
변경 프로세스를 준수해야하는 경우 변경 프로세스의 제한, 완전 중지에 따라 제한됩니다. 배포 전에 변경 사항을 승인해야하는 경우 연속 배포를 수행 할 수 없습니다. 승인 시간이 오래 걸리면 신속하게 배포 할 수 없습니다. 프로세스를 따르고 영향을받지 않는 해결 방법은 없습니다. 그것은 변화 과정을 따르는 비용이며, 그 과정에서 이해 관계자의 관심을 끌만 한 가치가 있습니다.
모든 것이 손실되지 않습니다 ... 오류를 최소화하기 위해 프로세스 주변 의 자동화 를 극대화 할 수 있습니다. 안정적인 아티팩트 생성과 해당 아티팩트를 프로덕션에 배치하는 것 사이의 연결을 제외한 모든 CD 단계 . 해당 연결은 일종의 사용자 개입 (버튼, CLI 명령 등)으로 대체되거나 승인 레코드에 연결됩니다 (예 : 변경 요청 티켓이 "승인 됨"상태로 이동하면 관련 배포가 종료 됨) ). 당신은 안장에 있던 모든 필수 절차를 따르는 동안 최대한 많은 혜택을 누려야합니다. 물론 승인이 더 빨라지지는 않습니다.