Pogodzenie ciągłego wdrażania ze ścisłymi zasadami zarządzania zmianami

Jestem ciekawy, jak inni architekci praktykują DevOps w środowisku ścisłego zarządzania zmianami, na przykład w procesie zatwierdzania rady doradczej Change (CAB) .

Rozumiem, że automatyzacja może usprawnić proces audytu, gwarantując bardziej rygorystyczny, możliwy do udowodnienia i powtarzalny proces. Ale wydaje się, że Ciągłe wdrażanie jest mniej lub bardziej niemożliwe w takiej sytuacji. Ponieważ zatwierdzenie zmian może potrwać tydzień lub dłużej, tracisz możliwość szybkiego i częstego wdrażania. Jakie kroki podejmujecie, aby pracować w ramach tych procesów, po prostu składając wnioski o zmianę i czekając na zatwierdzenie?

Jeśli musisz przestrzegać procesu zmiany, będziesz ograniczony zgodnie z ograniczeniami procesu zmiany, kropka. Jeśli zmiany muszą zostać zatwierdzone przed wdrożeniem, nie można wykonać ciągłego wdrażania. Jeśli zatwierdzenie zajmuje dużo czasu, nie można szybko wdrożyć. Nie ma obejścia, dzięki któremu można zarówno śledzić proces, jak i nie mieć na niego wpływu. Jest to koszt śledzenia procesu zmiany i jest to koszt, na który warto zwrócić uwagę interesariuszy tego procesu.

Nie wszystko jest stracone ... można maksymalizować automatyzację wokół procesu, w celu zminimalizowania błędów; wszystkie kroki CD, z wyjątkiem powiązania między wygenerowaniem stabilnego artefaktu a wdrożeniem tego artefaktu do produkcji. To powiązanie zostanie zastąpione przez jakąś interwencję użytkownika (przycisk, polecenie CLI itp.) Lub powiązane z zapisem zatwierdzenia (np. Gdy bilet żądania zmiany zostanie przeniesiony do stanu „zatwierdzonego”, uruchom odpowiednie wdrożenie ). Musisz po prostu wycisnąć z niego jak najwięcej korzyści, postępując zgodnie z obowiązkowym procesem, w którym zostałeś osiodłany. Oczywiście nie przyspieszy to zatwierdzania.