大多數企業都圍繞數據中心應用程序制定基本的遵從性和變更管理策略。有新的規則使變更管理和遵從性策略適應于云計算，主要關注軟件變更。
合規確保遵守與信息系統、數據存儲和使用相關的法規和內部政策。
變更管理確保受影響的各方正確地審查對應用程序和數據庫所做的更改，以便解決問題。
傳統的變更管理策略連接到開發過程，并且越來越多地連接到基于存儲庫的治理。任何級別的軟件更改以及任何中間件或操作系統更改都將通過存儲庫過程進行開發和測試。然后，企業可以應用變更管理來通知可能受到影響的利益相關者。
GitOps是DevOps的一個子集，是存儲庫驅動遵從性的擴展，將其擴展到部署。這可能改變應用程序的體驗質量(QoE)。它還引入了可能影響應用程序的新工具和api。此外，企業將GitOps模型應用到云應用程序中，當時主要是基于IaaS或容器的。
公司開始使用公共云提供商的api來訪問新的服務功能，但他們往往未能擴展其變更管理策略以納入新功能。因此，變革管理失敗了。即使在今天，CIMI公司發現幾乎一半的企業變更管理實踐都沒有涵蓋云托管功能的變化。
要使變更管理和遵從性策略適應云計算，請遵循以下規則。
適應當前流程的規則
規則1:利用現有資源
適應當前的變更管理和法規遵循政策和計劃，而不是創建新的。當前計劃的問題在于它們的范圍而不是行動。在云部署中，影響應用程序穩定性和QoE的因素可能是云部署前從未出現過的。我們的目標是確保現在包括了這些因素。
規則2:捕捉每一個變化
云更改管理策略必須捕獲云服務契約、服務承諾和云中的可計費更改中的所有更改。并非所有的云更改都需要更改軟件或存儲庫控制的中間件，有些可能不會進行常規測試。例如，對云托管區域或擴展限制的更改不會對軟件產生影響，但會損害QoE。將所有云更改視為軟件更改，并要求相同級別的涉眾參與。要遵循這一規則，需要明確地將云服務責任與軟件測試過程聯系起來。
規則3:評估工作流
在變更管理策略中考慮工作流變更。工作流表示從用戶到被訪問的應用程序的消息交換，以及支持這些消息交換所需的網絡連接。云應用程序通常由多個組件組成。由于云爆發和故障轉移設置，以及使用更復雜的技術(如服務網格)，一些組件進入和離開云。對這些內容的任何更改都可能直接改變穩定性、安全性和QoE。由于云提供商、互聯網、企業VPN或這些東西的任何組合提供網絡連接，服務質量可以產生第二級影響。
一旦覆蓋了非云變更管理實踐可能遺漏的變更來源，您還必須決定如何集成它們。目標是修改當前的實踐和程序。一個好的起點是規劃應用程序開發、測試和部署周期。在當前應用變更管理的每個點的流程上放置一個箭頭。然后獲取新的變更源，并決定將每個變更源映射到流中的位置。
執行測試
當在單元測試的基礎上進行云更改管理時，涉眾的經驗就會丟失。根據應用程序設計和部署模型的不同，可能存在有價值的子系統測試。
要確定情況是否如此，請遵循以下過程:
步驟1從變更管理流程早期的應用程序集成測試點回到每個測試點。
步驟2評估是否有足夠的功能組合在那里，并暴露在新的云相關的變化，以證明有意義的利益相關者審查結果。
步驟3停在那個不再正確的點上。
如果遵循這個過程，實際的變更管理程序不太可能需要太多的變更。
