デプロイメント戦略とは、チームが新しいコードを本番環境に反映させるために使用する方法です。バージョン間でトラフィックがどのように移行するか、各リリースがどれだけのリスクを伴うか、そして問題が発生した際にどれだけ迅速にロールバックできるかを決定します。この選択は理論上の話ではありません。戦略とシステムの間にミスマッチがあると、ダウンタイム、ロールアウトの失敗、あるいは数時間に及ぶ手動での復旧作業につながる可能性があります。
デプロイとは、コードを環境に配置することを意味します。リリースとは、そのコードをユーザーに公開することを意味します。一部の戦略では、これらを同一のイベントとして扱います。ローリングアップデートではインスタンスが置き換えられ、各インスタンスが稼働するたびにユーザーは新しいバージョンにアクセスするようになります。一方、これらを意図的に分離する戦略もあります。フィーチャーフラグを使えば、火曜日にデプロイして、社内での検証を経た後、木曜日にリリースするといったことが可能です。この分離が、この後のすべてのセクションの構成を形作っています。
デプロイメント戦略にはどのような種類がありますか？
どの戦略も、本番環境にどれだけのリスクをもたらすかと、セットアップにどれだけの労力がかかるかという2つの要素の間でトレードオフを行っています。ビッグバンデプロイメントは非常にシンプルですが、システム全体を停止させます。カナリアデプロイメントは本番トラフィックへの影響をほとんど与えませんが、機能させるにはトラフィック分割、メトリクス収集、自動分析が必要です。どちらの軸が優れているというわけではありません。適切な組み合わせは、何をデプロイするのか、そして失敗した場合に何が壊れるのかによって決まります。
ビッグバンデプロイメント
ビッグバンデプロイメントでは、新しいバージョンのインスタンスを起動する前に、現在のバージョンで実行中のすべてのインスタンスを停止します。トラフィック分割はなく、新旧コードの共存もなく、段階的なロールアウトもありません。Kubernetesでは、これはstrategy.type: recreateに相当します。
仕組み： デプロイメントコントローラーは、古いバージョンを実行しているすべてのpodを終了させた後、新しいバージョンのpodを起動します。トラフィックは、新しいpodがreadinessチェックに合格した後にのみ復帰します。
トレードオフは明快です。シンプルさとダウンタイムを引き換えにしています。後方互換性の要件はありませんが、その間ユーザーはアクセスできなくなり、その時間はアプリケーションの起動時間に応じて数秒から数分に及ぶことがあります。
ビッグバンは、ダウンタイムが許容できる場合に使用します。開発環境やステージング環境、スケジュールされたメンテナンスウィンドウ、あるいは破壊的な変更により2つのバージョンを同時に実行できない状況などです。
ローリングデプロイメント
ローリングデプロイメントでは、アプリケーションを稼働させたまま、インスタンスをバッチ単位で更新します。Kubernetesではこれがデフォルトの戦略であり（strategy.type: RollingUpdate）、maxUnavailableとmaxSurgeによって制御されます。
仕組み： デプロイメントコントローラーは、各ステップでreadinessプローブを確認しながら、新しいReplicaSetをバッチ単位でスケールアップし、同時に古いものをスケールダウンします。
ローリングデプロイメントは、環境を複製する必要がないため、リソース効率が高くなります。その代償はバージョンの共存です。新旧のバージョンが同時にトラフィックを処理するため、アプリケーションは後方互換性を保つ必要があります。ロールバックも即時には行われません。元に戻すには、逆方向にローリングを実行する必要があります。
ローリングデプロイメントは、インフラコストが重要な要素であり、後方互換性のある変更を行う場合に使用します。トラフィック分割の仕組みを持たないほとんどのチームにとって、これは妥当な出発点となります。
CircleCIのKubernetes orbは、get_rollout_statusコマンドによってローリングデプロイメントをサポートしています。このコマンドはロールアウトの進行状況を監視し、ロールアウトが停滞した場合にジョブを失敗させます。
ブルーグリーンデプロイメント
ブルーグリーンデプロイメントでは、同一の本番環境を2つ維持します。一方（ブルー）はすべてのトラフィックを処理し、もう一方（グリーン）は待機状態にあります。デプロイする際は、チームが新しいバージョンをグリーンにプッシュし、検証を行った後にトラフィックを切り替えます。何か問題が発生した場合は、1分以内にトラフィックをブルーに戻すことができます。
仕組み： 新しいバージョンは待機中の環境にデプロイされます。チームはそれに対してスモークテストや統合テストを実行します。検証が完了すると、トラフィックの切り替えが行われます。ロードバランサーのルール変更、Kubernetesサービスセレクターの更新、またはDNSの重み付けの変更などです。切り替え後に問題が発生した場合は、同じ仕組みを使ってトラフィックをブルーに戻します。
最も目に見えるコストは、コンピューティングリソースが2倍になることです。あまり気づかれにくいコストは、データベースに関するものです。両方の環境が同じデータベースを共有するため、スキーマの変更は両方のアプリケーションバージョンで同時に機能する必要があります。ブルーグリーンデプロイメントの失敗の多くはここで発生し、expand-migrate-contractパターンが重要になるのもこの点です。
expand（拡張）フェーズでは、既存のカラムやテーブルを削除せずに、新しいカラムやテーブルを追加します。migrate（移行）フェーズでは、既存のデータを新しい構造に取り込みます。contract（縮小）フェーズでは、すべてのトラフィックが新しいコード上で稼働するようになった時点で、古いカラムを削除します。各フェーズは個別のデプロイとして実行され、常にN-1互換性という制約が存在します。つまり、新しいアプリケーションバージョンは前のスキーマでも動作し、その逆も成り立つ必要があります。
ブルーグリーンデプロイメントは、ロールバックの速度が絶対的な要件であり、チームがインフラコストを負担できる場合に使用します。
CircleCIのワークフローは、手動承認ゲートを通じてブルーグリーンデプロイメントをサポートしています。パイプラインは待機中の環境にデプロイし、検証ジョブを実行した後、エンジニアが切り替えを確認するまで承認ステップで待機することができます。
カナリアデプロイメント
カナリアデプロイメントでは、本番トラフィックのうち通常1〜5%程度の少量を新しいバージョンに送り、残りは現在のバージョンで処理を続けます。カナリアのメトリクスが健全であれば、トラフィックは徐々に増加します。メトリクスが悪化した場合は、すべてのトラフィックが現在のバージョンに戻されます。
仕組み： トラフィック管理層（ingressコントローラー、サービスメッシュ、またはArgo Rollouts）が、定義された割合のリクエストを新しいバージョンにルーティングします。モニタリングシステムは、カナリアとベースラインの両方からメトリクスを収集します。定義された観測期間の後、トラフィックは増加するか、ロールバックされます。
カナリアデプロイメントは、自身のトラフィック分を処理できる分のインスタンスしか必要としないため、ブルーグリーンデプロイメントよりもコストが低くなります。一方で複雑さのコストは高くなります。トラフィック分割の仕組み、リアルタイムでのメトリクス比較、自動分析が必要になるためです。これらがなければ、単に手順が増えたローリングデプロイメントに過ぎません。Kayenta（GoogleとNetflixが開発）とArgo Rolloutsは、いずれもカナリアメトリクスの統計分析に基づいて、プロモートかロールバックかの判断を自動化します。
CircleCIは、自社の本番サービスの大部分においてカナリアデプロイメントにArgo Rolloutsを社内利用しています。CircleCI release agentはArgo Rolloutsと統合されており、チームはCircleCIのデプロイUIから直接、カナリアロールアウトのプロモート、ロールバック、キャンセルを行えます。
A/Bテストデプロイメント
A/Bテストデプロイメントでは、コンバージョン率、セッションあたりの収益、エンゲージメントといったビジネスメトリクスを測定するために、ユーザーセグメントに基づいて異なるアプリケーションバージョンにトラフィックをルーティングします。カナリアデプロイメント（安全性のためにランダムに分割する）とは異なり、A/Bテストはビジネス上の問いに答えるために特定のユーザーグループを対象とします。
仕組み： チームは、特定の地域のユーザー、モバイルユーザー、あるいは一貫したハッシュ関数によって割り当てられた割合など、セグメンテーションルールを定義します。両方のバージョンが同時に稼働し、その間に分析システムが対象のメトリクスを収集します。実験が統計的有意性に達すると、優れた結果を出したバージョンが全ユーザーに展開されます。
A/Bテストは実験のための手法であり、リスク軽減のための戦略ではありません。両方のバージョンが安定しており、本番環境で使用できる状態であることを前提としています。エラー率やレイテンシーによって自動的にトリガーされるロールバックが存在しないため、リスクプロファイルはカナリアデプロイメントよりも高くなります。
A/Bテストは、目的が安全性ではなく最適化である場合に使用します。セグメンテーション層、分析パイプライン、そして統計的有意性に達するために十分なトラフィック量が必要です。
シャドウデプロイメント
シャドウデプロイメントでは、実際の本番トラフィックを、現在のバージョンと並行して稼働する新しいバージョンにミラーリングします。現在のバージョンがユーザー向けのすべてのレスポンスを処理します。シャドウバージョンは同じリクエストを処理しますが、そのレスポンスがユーザーに提供されることはありません。レスポンスはログに記録され、検証のために本番の出力と比較されます。
仕組み： トラフィックミラーリング層が受信リクエストを複製し、そのコピーをシャドウ環境に送信します。レスポンスは、リアルタイムまたはバッチ処理のいずれかの方法で、本番バージョンのレスポンスと比較されます。
シャドウデプロイメントは、ユーザーに影響を与えることが一切ないため、実際のトラフィックに対してテストを行う最も安全な方法です。そのため、MLモデルの切り替え、アルゴリズムの書き換え、データベース移行の検証などに適しています。主な制約はステートフルな処理に関するものです。シャドウバージョンがデータベースへの書き込みや決済処理を行う場合、それらの処理は2回実行されてしまいます。書き込みを伴う副作用があるサービスをミラーリングするには、そうした経路をフィルタリングする必要があり、それによってテストの忠実度は低下します。
フィーチャーフラグデプロイメント
フィーチャーフラグデプロイメントでは、コードのデプロイとユーザーへのリリースを分離します。新しいコードは、デフォルトで「オフ」になっているフラグの背後に隠された状態で本番環境に配信されます。準備が整った時点で、チームは特定のユーザー、割合、セグメントに対してフラグをオンにします。何か問題が発生した場合は、フラグをオフに切り替えることで、その変更を即座に非表示にできます。
仕組み： フィーチャーフラグプラットフォーム（LaunchDarkly、Unleash、Flagsmith、あるいは自社開発のサービス）がフラグの設定を保存し、SDKを通じてアプリケーションに提供します。エンジニアがフラグを切り替えると、その変更は数秒以内に反映されます。新たなデプロイ、podの再起動、ロードバランサーの変更は一切必要ありません。
フィーチャーフラグは、トランクベース開発、社内でのドッグフーディング、そしてアプリケーションレベルでの即時ロールバックを可能にします。このリストにある他のどのデプロイメント戦略とも自然に組み合わせることができます。トレードオフとなるのはフラグの負債です。機能がリリースされた後もコードベースに残り続けるフラグは、コードを煩雑にし、テストの範囲を広げてしまいます。この対策には規律が必要です。すべてのフラグに期限を設定し、フラグの削除を機能の完了条件の一部として扱うようにしましょう。
イミュータブルデプロイメント
イミュータブルデプロイメントでは、既存のインフラをその場で変更するのではなく、完全に置き換えます。変更が発生するたびに新しいアーティファクト（コンテナイメージ、VMイメージ、AMI）が生成され、それが新しいインスタンスにデプロイされます。稼働を開始した後のインスタンスに対して、パッチの適用や再設定が行われることは一切ありません。
仕組み： CIパイプラインがアプリケーションをビルドし、イミュータブルなアーティファクトにパッケージ化して、レジストリにプッシュします。新しいインスタンスはそのアーティファクトから作成され、古いインスタンスは終了されます。
イミュータビリティは、設定ドリフトの問題を解決します。設定ドリフトとは、インスタンスが本来実行しているべき状態と、実際に実行している状態との間に生じる徐々のズレのことです。コンテナはその設計上これを実現しますが、この原則はPackerで構築されたAMIやNixベースの設定にも当てはまります。AWSは、Well-Architected Frameworkの中でイミュータブルなインフラストラクチャを取り上げています。その代償は、より厳格なビルドプロセスであり、すべての変更が完全なビルド・テスト・デプロイのサイクルを必要とすることです。
イミュータビリティはトラフィックのルーティングに関する選択ではありません。これはアーティファクトをどのように構築するかに関する決定であり、このリストにある他のどの戦略とも組み合わせることができます。
GitOpsベースのデプロイメント
GitOpsデプロイメントでは、各環境で何を稼働させるべきかについての単一の信頼できる情報源としてGitリポジトリを使用します。クラスタ内で稼働するエージェント（ArgoCD、Flux）が、実際の状態とGitで宣言された状態を継続的に比較し、ズレがあれば修正します。
仕組み： チームは、Kubernetesマニフェスト、Helmチャート、またはKustomizeオーバーレイをGitリポジトリに保存します。エンジニアがプルリクエストをマージすると、エージェントが新しいコミットを検知して適用します。誰かがクラスタ内のリソースを手動で編集した場合、エージェントはそれをGitの内容に合わせて元に戻します。
OpenGitOpsプロジェクトは、次の4つの原則を定義しています。望ましい状態は宣言的であること、Git内でバージョン管理されイミュータブルであること、エージェントによって自動的にプルされること、そして継続的に修正されること。プル型のモデルであるため、クラスタの認証情報がクラスタの外部に出ることはありません。
トレードオフは適用範囲です。ArgoCDとFluxはKubernetes専用に構築されています。VM、サーバーレス、あるいはハイブリッド環境で作業するチームは、この原則を採用することはできますが、同じような標準搭載の修正機能は得られません。
CircleCIとArgoCDはよく組み合わせて使われます。CircleCIがビルド、テスト、イメージのプッシュの各ステージを実行し、GitOpsリポジトリ内のイメージタグが更新されると、ArgoCDがデプロイを行います。
適切なデプロイメント戦略を選ぶ方法
デプロイメント戦略を比較することで、デプロイメントへの対応方法について大まかな全体像を把握できます。しかし、それだけでなく、プロジェクトとその要件に固有の要素についても考慮する必要があります。ここでは、プロジェクトに適したデプロイメント戦略を選ぶ際に役立つ、5つの重要な要素を見ていきましょう。
- ダウンタイムの許容度。 デプロイ中にシステムをオフラインにできますか？メンテナンスウィンドウ中の短時間であっても許容できるのであれば、ビッグバンデプロイメントも選択肢の一つとなります。許容できない場合は、ビッグバンデプロイメントは除外してください。ロールアウト中の短時間のバージョン共存も許容できない場合、残る選択肢はブルーグリーン、カナリア、またはフィーチャーフラグです。
- インフラ予算。 チームは本番環境全体を複製して運用できますか？可能であれば、ブルーグリーンデプロイメントが有効です。難しい場合は、自身のトラフィック分を処理できる分のインスタンスしか必要としないカナリアデプロイメントの方が適しています。ローリングデプロイメントは既存のキャパシティを再利用するため、すべての中で最もコストが低くなります。多くのチームにとって、予算の制約によってブルーグリーンデプロイメントは選択肢から外れます。
- チームの成熟度とツール。 チームはトラフィック分割の仕組み（サービスメッシュ、重み付けされたingress、またはArgo Rollouts）を持っていますか？カナリアとベースラインの間でメトリクスの自動比較を実行できますか？どちらかの答えが「いいえ」であれば、まずローリングデプロイメントとフィーチャーフラグから始めましょう。必要なツールが整った時点で、カナリアデプロイメントへと発展させていきます。モニタリングの仕組みがないままカナリアデプロイメントを行うと、リリースごとに誰かが手動でダッシュボードを監視する必要が生じ、これはスケールしません。
- アーキテクチャ。 モノリスは単一のユニットとしてデプロイされるため、ブルーグリーンやローリングが最も適しています。マイクロサービスは、各サービスが独自のスケジュールで個別にロールアウトされるカナリアデプロイメントやプログレッシブデリバリーの恩恵を受けます。サーバーレス関数は、クラウドプロバイダーがインフラを管理しており、ルーティングの対象となるインスタンスが存在しないため、フィーチャーフラグによる制御が最適です。
- コンプライアンスと監査要件。 規制の厳しい業界では、何が、いつ、誰によってデプロイされたかについての完全な監査証跡が必要となることが多くあります。GitOpsは、これを標準で提供します。すべての変更が、作成者とレビュー履歴を持つGitコミットとして記録されるためです。一部のコンプライアンスフレームワークでは、トラフィック切り替え前に環境全体の検証が求められ、これはブルーグリーンデプロイメントに有利に働きます。チームがSOC 2、HIPAA、またはPCI-DSSの下で運用している場合、デプロイメント戦略はエンジニアだけでなく監査担当者も満足させる必要があります。
実際には、ほとんどのチームは単一のデプロイメント戦略だけに依存することはありません。カナリアが安定性を検証し、フィーチャーフラグが変更を見るユーザーを制御し、GitOpsがそれをどのように適用するかを管理します。これらの手法が組み合わさって、自動化されたデータドリブンなリリースプロセスとなったとき、その組み合わせはプログレッシブデリバリーと呼ばれます。
プログレッシブデリバリーとは何ですか？
プログレッシブデリバリーは、単独の戦略ではなく、一つの枚組みです。この用語は、2018年にRedMonkのJames Governorによって作られたもので、制御された範囲でソフトウェアをリリースする手法を表しています。つまり、少数のユーザーにデプロイし、その結果を観察した上で、データに基づいて対象を広げていくというものです。カナリアデプロイメント、フィーチャーフラグ、A/Bテスト、ブルーグリーンデプロイメントは、いずれもこの枚組みに含まれます。プログレッシブデリバリーが加える要素は、これらの手法が連携して機能し、ロールアウトの各段階を自動化されたガードレールが管理するという前提です。
実際には、プログレッシブデリバリーのパイプラインは次のような形になります。CIシステムがアーティファクトをビルドし、テストします。そのアーティファクトは、トラフィックの2%を受け取るカナリアの背後にデプロイされます。自動分析の実行が、10分間にわたってエラー率とレイテンシーをベースラインと比較して確認します。メトリクスが基準を満たせば、トラフィックは25%、次に50%、そして100%へと増加し、各段階で分析が行われます。いずれかの段階で失敗した場合、トラフィックは自動的に前のバージョンに戻されます。フィーチャーフラグをその上に重ねることで、コードが完全にロールアウトされた後でも、どのユーザーが新しい機能を見るかを制御できます。
場当たり的なモニタリングチェックと手動承認をつなぎ合わせて運用しているチームにとって、プログレッシブデリバリーとは、まさに自分たちが構築しようとしているものの名前なのです。
CI/CDパイプラインでデプロイメント戦略を設定する方法
CI/CD（継続的インテグレーションと継続的デリバリー）とは、コードのビルド、テスト、配信の方法を自動化する手法です。CIの側面では、コードの変更を頻繁にマージし、それぞれに対して自動テストを実行します。CDの側面では、テストに合格したビルドを本番環境へと進めます。デプロイメント戦略が決定するのは、その最終段階で何が起こるかです。つまり、新しいバージョンがどのようにユーザーに届くか、トラフィックがどのように移行するか、そして問題が発生した場合に何が起こるかです。ここでパイプラインの設計が重要になります。
デプロイメント戦略ごとに、パイプラインの形は異なります。パイプラインは、デプロイメントを最後の単一のステップとして扱うのではなく、戦略の各段階を明示的に反映させる必要があります。
実際の例を見てみましょう。以下は、Argo Rolloutsを使用したカナリアデプロイメントのための、簡略化されたCircleCI設定です。
workflows:
deploy:
jobs:
- build
- test:
requires: [build]
- push-image:
requires: [test]
- update-manifests:
requires: [push-image]
# Argo Rollouts handles canary traffic shifting
# CircleCI release agent monitors rollout progress
CIパイプラインは、アーティファクトの配信までのすべてを処理します。Argo Rolloutsは、カナリアのトラフィック移行、分析の実行、自動プロモートを処理します。CircleCIのrelease agentがこの2つを連携させ、チームはロールアウトの進行状況を可視化し、CircleCIのデプロイダッシュボードから直接プロモート、キャンセル、ロールバックを行えるようになります。Argo Rolloutsを使用していないチームの場合、CircleCIのデプロイマーカーが各デプロイメントを追跡し、Webアプリから直接、以前の安定版に戻すことができるロールバックパイプラインを有効にします。
ブルーグリーンデプロイメントの場合、CircleCIワークフローの承認ゲートが、構造化された保留ポイントを提供します。カナリアデプロイメントの場合、Argo RolloutsのAnalysisRunリソースがメトリクスプロバイダーに問い合わせを行い、閾値を満たしていれば自動的にプロモートします。フィーチャーフラグデプロイメントの場合、プロモートかロールバックかの判断は、フラグプラットフォーム自体に委ねられます。
データベースのマイグレーションは、必ず個別に処理してください。ブルーグリーンデプロイメントのセクションで説明したexpand-migrate-contractパターンは、パイプラインにおいて第一級の関心事として組み込む必要があります。スキーマのマイグレーションは、アプリケーションのデプロイが始まる前に、独自のステージで実行します。expandステップは最初にデプロイされ、現在稼働しているコードと後方互換性を持つ必要があります。contractステップは、古いスキーマが使用されなくなったことを確認した後、後続のパイプラインで実行します。どの段階であってもN-1互換性に違反すると、ロールバックが失敗することになります。
デプロイメント戦略のベストプラクティス
- シンプルに始めて、徐々に複雑さを取り入れる。 ローリングデプロイメントは妥当なデフォルトの選択です。モニタリングとトラフィック分割の仕組みが整った段階でカナリアデプロイメントを追加しましょう。初日からプログレッシブデリバリーに飛びつかないでください。
- デプロイだけでなく、ロールバックも自動化する。 ロールバックが手動であれば、それは遅くなります。遅ければ、チームはデプロイをためらうようになります。そのためらいが、より大きく、よりリスクの高いバッチにつながります。ロールバックが自動化され、デプロイがリスクの低い行為だと感じられるほど十分に速くなれば、この悪循環は断ち切られます。
- デプロイだけでなく、カナリアも監視する。 すべてのリリースの最中および直後に、エラー率、レイテンシーのパーセンタイル（p50、p95、p99）、ビジネスメトリクスを追跡しましょう。唯一のヘルスチェックが「コンテナが起動したかどうか」だけであれば、誰も気づく前に問題がユーザーに届いてしまいます。
- 可能な限り、デプロイとリリースを分離する。 フィーチャーフラグを使うことで、コードが本番環境に到達するタイミングとは独立して、ユーザーが変更を目にするタイミングをチームが制御できるようになります。
- デプロイメントパイプラインをコードとして扱う。 バージョン管理し、レビューし、テストしましょう。パイプラインの設定がバージョン管理の外にある場合、それは単一障害点となります。
- データベースについて事前に計画する。 expand-migrate-contractパターンは、最初のブルーグリーン切り替えの失敗の後に導入するものではなく、最初からチームのワークフローの一部として組み込まれているべきです。
デプロイメント戦略のツール
ほとんどのチームは、以下のすべてのカテゴリーのツールを必要とするわけではありません。適切なツールの組み合わせは、どの戦略を選んだか、そして既にどのようなインフラを持っているかによって決まります。
CI/CDプラットフォームは、ビルド・テスト・デプロイのパイプラインを実行します。CircleCIは、ワークフローのオーケストレーション、承認ゲート、デプロイマーカー、ロールバックパイプライン、そしてKubernetesとArgo Rolloutsとの統合のためのrelease agentを提供します。GitHub Actions、GitLab CI、Jenkinsも、他によく使われる選択肢です。
プログレッシブデリバリーおよびカナリアコントローラーは、Kubernetes上でトラフィックの移行と自動分析を処理します。Argo Rolloutsが最も広く採用されています。FlaggerとSpinnakerも同様の機能を提供しています。
GitOpsエージェントは、クラスタの状態をGitリポジトリの内容と一致させるように修正します。ArgoCDとFluxが2つの主要な選択肢であり、いずれもCNCFのgraduatedプロジェクトです。
フィーチャーフラグプラットフォームは、デプロイメントとは独立してリリースのタイミングを制御します。LaunchDarkly、Unleash、Flagsmithは、いずれもSDKベースのフラグ評価とユーザーターゲティングを提供します。
トラフィック管理は、カナリア、A/B、シャドウデプロイメントに必要な重み付けルーティングを実現します。Istio、Linkerd、AWS ALBの重み付けターゲットグループは、それぞれ異なる複雑さのレベルでこれをサポートしています。
カナリア分析は、プロモートかロールバックかの判断を自動化します。Kayenta、Datadog、Prometheus + Grafanaは、いずれもArgo Rolloutsのようなツールにメトリクスを供給できます。
ツールそのものよりも、実践のあり方の方が重要です。とはいえ、CI/CDプラットフォームは、他のすべてが接続される基盤となります。CircleCIは、段階的なワークフロー、承認ゲート、デプロイの追跡、ロールバックを標準で備えており、チームはデプロイメントインフラを構築するための時間を減らし、より多くの時間をリリース作業に充てられるようになります。
まとめ
デプロイメント戦略とは、チームがリリースごとにどれだけのリスクを許容し、問題が発生した際にどれだけ迅速に復旧する必要があるかについての決定です。唯一の正解はありません。メンテナンスウィンドウ中の破壊的なマイグレーションには、ビッグバンデプロイメントが正しい選択です。トラフィックの多い本番サービスには、自動分析を備えたカナリアデプロイメントが正しい選択です。ほとんどのチームは、複数の戦略を組み合わせて使用することになるでしょう。
正しい答えは、システム、チーム、そして賭けられているものによって決まり、この3つすべてが成長するにつれて変化していきます。今日うまく機能するものから始め、チームが次に必要とするものへと向けて構築していきましょう。
CircleCIを無料で始めて、デプロイメントドキュメントを確認し、デプロイの追跡、ロールバックパイプライン、Kubernetesのリリース管理を設定してみましょう。
