Control-M + GCPデプロイメントマネージャー

GCPデプロイメントマネージャーのワークフローは、デプロイメント構成が実行される前に開始されます。そして、上流で何かが壊れると失敗する可能性があります。Cloud Storageの構成アーティファクトが遅れて到着します。GitHub Actionsの検証ワークフローがデプロイメントウィンドウの数分前に失敗します。Control-Mは、構成の到着、CIの検証、GCPデプロイメントマネージャーの実行、下流の検証をオーケストレーションします。

あなたのようなパイプラインで見る統合の事実を見る

共通のワークフローの問題

今週のあなたの状況に聞こえますか？

これらはエッジケースではありません。これらは、複数のツールでGCPデプロイメントマネージャーのデプロイメントを実行しているチームの通常の運用条件です。Control-Mが各ケースをどのように処理するかをご覧ください。

上流の失敗

あなたのYAMLは準備ができました。GitHub Actionsの検証ジョブが最初に失敗しました。

Control-Mはデプロイメントをリリースする前に上流ジョブの状態を評価し、失敗した検証がGCPにカスケードするのを防ぎ、依存している作業がその条件を満たすまで待機するようにします — 検証されていない構成から構築されたデプロイメントを回避します。

デプロイメントの失敗

デプロイメントが始まりました。GCPリソース操作は決して成功裏に完了しません。

Control-Mはデプロイメントマネージャーのジョブのステータス、結果、出力を監視し、構成可能なステータスポーリングと失敗耐性を使用して実行状態を判断します。デプロイメントが失敗すると、下流ジョブはゲートされ、依存する生産作業が始まる前に影響を抑えます。

リリース調整

コンピュートエンジンがプロビジョニングされています。アプリケーションのロールアウトが早すぎます。

Control-Mはデプロイメントとアプリケーションのロールアウトを明示的な依存関係として1つのワークフローでモデル化します。インフラストラクチャステップがその完了基準を満たすまで、下流のリリースは実行されず、プラットフォームとアプリケーションチーム間の切り離されたスケジュールや手動の引き継ぎを排除します。

SLAリスク

デプロイメントが実行中ですが、プロダクションウィンドウが急速に閉じています。

Control-MはSLA管理をデプロイメントマネージャーのジョブに添付し、より広いワークフロー内で評価します。オペレーターは、依存するサービスがウィンドウを逃す前に介入する時間がある間、締切のリスクを可視化します。

移行リスク

デプロイメントマネージャーは引退します。プロダクションの依存関係は、すべてのデプロイメントを囲んでいます。

チームが既存のデプロイメントマネージャーのエステートを移行する際、Control-Mは周囲のアプリケーションと運用の依存関係を共通のワークフローで可視化します。そのオーケストレーション層は、チームが生産サービスが依存するアップストリームとダウンストリームのプロセスを失うことなく、移行作業を調整するのに役立ちます。

統合の事実