継続的デプロイメントとは何か？

継続的デプロイメントとは何ですか？Continuous Deliveryとはどう違うのですか？あるいは、Continuous Integrationとも違うのでしょうか？ご心配なく。私たちはその答えを知っています。

Googleで「devops continuous...」と入力すると、検索ページに収まりきらないほどの用語が返されます。「continuous integration、continuous delivery、continuous deployment、continuous monitoring...」といった具合です。正直なところ、ちょっと手に負えなくなっています。

図　冗談じゃなかったんです

「Continuous何とか」は、業界の新しいバズワードになっています。しかし、そのため、これらの用語の意味を定義し、調べることが難しくなっています。特に、どれも似た用語に見える場合はそうです。例えば、「Continuous Delivery」（継続的デリバリー）と「Continuous Deployment」（継続的デプロイメント）みたいに。この２つの違いは一体何でしょうか？単なる意味上の違いなのでしょうか？デプロイとデリバリーには、大きな違いがあることが分かりました。継続的デプロイプロセスとデプロイメントパイプラインは、Continuous Deliveryプロセスの一部ですが、それぞれの目指すとことは別です。

この記事では、Continuous DeploymentとContinuous Deliveryの手法を比較対照する予定です。また、Continuous Deploymentが開発チームにどのようなメリットをもたらすかを理解するために、深く掘り下げる予定です。

継続的デプロイメントとContinuous Deliveryの比較

その名が示すように、Continuous Deployment は、機能とアップデートのインストールと配布に焦点を当てます。一般的に、Continuous Integrationプロセスの後、アプリケーションはいくつかの下位レベルの環境を通過します。QAチームは、回帰テスト、ユニットテスト、またはテスト自動化を実行して、コードが高品質であることを確認するかもしれません。アプリケーションは、下位レベルの環境を経た後、本番環境へとプッシュされます。これらの段階をすべて自動化したものを、私たちは「継続的デプロイメント・パイプライン」と呼んでいます。目標は、さまざまなトリガーと繰り返し可能なステップを使用することによって、必要な人間の介入量を減らすことです。

一方、Continuous Deliveryには、継続的デプロイメントの全ての自動化ステップが含まれますが、セキュリティ、コンプライアンス、および検証の自動化が追加され、各デプロイメントに関連するリスクを低減します。したがって、Continuous Delivery・パイプライン（CDパイプライン）には、ガバナンスの承認ステップ、カナリアやブルーグリーンデプロイメントのような安全なデプロイメント戦略、エンドユーザーにとってすべてが最適に機能していることを確認するためのデプロイメント後の検証を含む必要があります。

Continuous DeploymentとContinuous Deliveryの違いについては、リンク先のブログ記事をご覧ください。

継続的デプロイメントの原則

第1部：アーティファクト

継続的デプロイは、新しいコードをアーティファクトにパッケージ化した時点で始まります。CIプロセスが完了すると、２つのアプローチがあります。一方のアプローチは、その会社が通常のデプロイメント・ケイデンスに達するまで、アーティファクトをレポに保存しておくことができます。デプロイサイクルが週次デプロイしか推進しない、規制の厳しい業界でコンプライアンスルールが多い、デプロイする下位の環境が少ないなど、遅延の理由はさまざまです。いずれにせよ、最初のデプロイメントプロセスを遅らせることを選択した企業でも、サイクルの後半で継続的デプロイメントを実践できます。もう１つのアプローチは、新しいコード変更を直ちに開発統合環境または品質保証環境にデプロイして、統合テストを開始することです。これらの下位レベルの環境はリスクが低いので、継続的デプロイメントの考え方を取り入れるには、このような環境が適しています。

第2部：デプロイメントの自動化

次のステップは、下位の環境へのデプロイと下位の環境間のデプロイの自動化を検討することです。ここで、パイプラインを利用してデプロイメントを標準化することが重要になります。ソフトウェア開発では、理想的な世界は毎日いくつもデプロイ可能な成果物が作成される世界ですが、標準化されていないやり方は、すぐにボトルネックになってしまいます。このゲームの目的は、他の開発者が容易に理解でき、全てのデプロイメントで再現可能で、他のチームにも拡張可能なパイプラインを作ることです。企業が陥りやすい落とし穴は、各環境や各チームごとに独自のデプロイメントパイプラインを作成することです。一見すると、超特殊なデプロイメント戦略を立てることは理にかなっているように思えますが、結局はメンテナンスの悪夢となります。テスト環境に成果物をデプロイするのに数分もかからないようにし、パイプラインの運用を維持するためのメンテナンスも最小限にとどめるべきです。

第3部：本番

継続的デプロイメントの最後の主要コンポーネントは、本番環境でのデプロイメントそのものです。本番環境での最小限のゴールドスタンダードは、ローリングデプロイメントを実行することです。このタイプのデプロイは、全てのノードが新しいバージョンになるまで、古いアプリケーションノードをインクリメンタルレベルで、通常は１つずつ置き換えていきます。これは、デプロイが成功したことを確認するために検証ツールを使いながら、新しいバージョンに切り替えるという安全な方法です。その他のデプロイメント方法としては、ブルーグリーンデプロイメントやカナリアデプロイメントが考えられます。大事なのは、スケーリングの複雑さを軽減するために、会社のアプリケーション全体で標準的なデプロイメント戦略を採用する必要があるということです。

継続的デプロイメントの実践

継続的デプロイメントについて議論するのは、一部のことにしか過ぎません。組織で実践するのは、また別の話です。ここでは、真の継続的デプロイメントプロセスに向けて前進しているHarnessのお客様の事例をご紹介します。

Choice Hotelsは、自動化の作成に大量のリソースを費やしながらも、全ての自動化を継続的なプロセスに合理化する良い方法を持っていませんでした。そのため、デプロイは週に１度、午後10時にしか行えず、合計で12時間かかっていました。Harnessは、Choiceが自動化を活用してデプロイ作業を２時間に短縮し、チームが１週間のうちいつでもデプロイできるようにするのを支援しました。お客様の言葉を引用します。「Harnessは、全てを単一のパイプラインに合理化することで、自動化ツールへの投資を有効活用するのに役立っています。

• Zeptoは、遅くて信頼性の低いソフトウェアデプロイメントに悩まされていました。「ソフトウェアのデプロイとスクリプトのメンテナンスのために、最もコストのかかるビジネスリソースを使わなければなりませんでした」とCTOのTrevor Wistaffは述べています。そのため、Zeptoは週に２回しかデプロイできない状態でした。しかし、Harnessを導入したことで、デプロイにかかる時間は20分から１分未満に短縮されました。このスピードと信頼性の向上により、Zeptoは１日に３回、新機能をデプロイできるようになりました。

最後の考察

組織の規模が大きくなるにつれて、さまざまな関係者がエンジニアリングプロセスの自動化を望むようになります。しかし、顧客への最終的なリリースに時間がかかるようでは、いくら自動化を進めても意味がありません。継続的デプロイメント戦略は、このプレッシャーを軽くし、新しいコードとバグフィックスをより早く顧客に届けることを可能にするはずです。

継続的デプロイをどのように導入するかお悩みでしたら、Harnessをご覧ください。当社のCDソリューションは、継続的デプロイメントの複雑さを解消し、優れたソフトウェアの構築に専念できるようにします。

CDについてもっと知りたいですか？　私たちのeBook、 Pipeline Patternsをぜひご覧ください。パイプラインを最適化し、デプロイの失敗を減らし、ニーズに合った最適なパイプラインを選択するのに役立つ、非常に貴重なリソースです。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。