Sürekli Dağıtım'ı katı değişiklik yönetimi politikalarıyla uzlaştırma

Başkalarının DevOps uygulamalarını Değişiklik danışma kurulu (CAB) onay süreci gibi katı bir değişiklik yönetimi ortamında nasıl tasarladıklarını merak ediyorum .

Otomasyonun daha titiz, kanıtlanabilir ve tekrarlanabilir bir süreci garanti ederek denetim sürecinizi iyileştirebileceğini anlıyorum. Ancak böyle bir durumda Sürekli Dağıtım'ın neredeyse imkansız olduğu düşünülmektedir. Değişikliklerin onaylanması bir hafta veya daha fazla zaman alabileceğinden, hızlı ve sık dağıtım yeteneğini kaybedersiniz. Yalnızca değişiklik istekleri göndermek ve onay beklemek dışında bu süreçlerde çalışmak için hangi adımları atıyorsunuz?

Değişiklik sürecine bağlı kalmanız gerekiyorsa, değişiklik sürecinin sınırlamaları, tam durak ile sınırlı olacaksınız. Değişikliklerin dağıtımdan önce onaylanması gerekiyorsa, sürekli dağıtım yapamazsınız. Onay çok uzun sürerse, hızlı bir şekilde dağıtamazsınız. Hem süreci takip edebileceğiniz hem de bundan etkilenmeyeceğiniz bir çözüm yoktur. Değişim sürecini takip etmenin maliyeti budur ve bu süreçte paydaşların dikkatini çekmeye değer bir maliyettir.

Her şey kaybolmaz ... hataları en aza indirmek için süreç etrafındaki otomasyonu en üst düzeye çıkarabilirsiniz ; istikrarlı bir artefakt oluşturma ve bu artefaktı üretime dağıtma arasındaki bağlantı haricindeki tüm CD adımları . Bu bağlantı bir tür kullanıcı müdahalesi (düğme, CLI komutu, vb.) İle değiştirilir veya onay kaydına bağlanır (örneğin bir değişiklik isteği bileti "onaylandı" durumuna getirildiğinde, ilgili dağıtımı durdurur ). Üzüldüğünüz herhangi bir zorunlu işlemi takip ederken, bundan olabildiğince fazla fayda elde etmek zorundasınız. Elbette onayları daha hızlı hale getirmez.