継続的デプロイを理解しよう
継続的デプロイ（CD）は継続的インテグレーションと継続的デリバリー（CI/CD）のプロセスを拡張したもので、正常に完了した個々のコードの変更を自動的にデプロイすることによって実現されます。
継続的デプロイとは？
継続的デプロイは、ビルド、テスト、デプロイのステップを自動化する DevOps の手法を極限まで押し進めるものです。 コードの変更がパイプラインの各ステージを通過すると、その変更が人の介入なしで自動的に本番環境にデプロイされます。 継続的デプロイを採用すると、新機能を品質を損なうことなく最速でユーザーに提供できるようになります。
継続的デプロイは、成熟した実証済みの継続的インテグレーションと継続的デリバリーのプロセスによって支えられています。
- チームメンバーは定期的に小さな単位でコードの変更をコミットします。
- コミットするたびに自動テストとビルドプロセスがトリガーされます。
- ビルドはさまざまな本番前環境を通過し、さらには自動テストが行われます。
- 問題が検出されなければ、新しいバージョンのソフトウェアがユーザーにリリースされます。
安定した信頼性の高い CI/CD プロセスを導入したら、最後のステップを自動化して変更を自動的にユーザーにデプロイできるようになります。 継続的デプロイを導入すると、リリースは特別なイベントではなくなり、1 日に何度も行われるようになります。
とは言え、継続的デプロイをあらゆる DevOps チームの最終目標とすべきだと考えるべきではありません。 アプリ、API、またはインストール済みのソフトウェアをビルドしている場合、ユーザーは 1 日に何度も更新を受け取ることを望まない可能性があります。 このような場合は、継続的デリバリーの方が適しているかもしれません。
デプロイパイプラインを完全に自動化しない場合でも、いくつかの手法を厳選して独自の CI/CD プロセスに適用することもできます。 すべてを継続的に処理する前に、継続的デプロイには実際に何が伴うのか、何を考慮すべきなのかを詳しく見てみましょう。
継続的デプロイと継続的デリバリーの比較
混同しがちですが、継続的デプロイと継続的デリバリーはそれぞれ CI/CD パイプラインの CD 側で明確に異なる役割を担っています。 継続的デリバリーでは本番環境への最終的なリリースを手動でトリガーする必要がありますが、継続的デプロイではリリース前のすべてのステップが正常に完了する限りは自動的にリリースが行われます。
継続的デプロイと継続的デリバリーの比較
| 継続的デプロイ | 継続的デリバリー | |
|---|---|---|
| リリースモデル | コードの変更がパイプラインの各ステージを正常に通過すると自動的にトリガーされる。 | パイプラインの各ステージを正常に通過した変更に対して手動で開始される。 |
| リリースの頻度 | 1 時間に多くとも数回（チームの規模とパイプラインの速度による）。 | 通常は毎週または毎月。ただし、頻度は自由に決定できる。 |
| 最適な用途 | ウェブサイトとウェブアプリケーション。 | モバイルアプリ、デスクトップソフトウェア、API。 また、継続的デプロイへの布石として使用することもできる。 |
| テストプロセス | 完全に自動化されており、非常に安定していることが必要。 クオリティゲートの導入により、開発者と関係者はテストがあらゆるバグが検出されることを確信できる。 | 最大限に自動テストを使用することが推奨される。 リリースプロセスの頻度が低いため、承認ち探索的テストを手動で実施する余裕がある。 |
| その他の考慮事項 | カナリアデプロイとブルーグリーンビルドにより、本番環境にリリースされる問題の影響を最小限に抑えられる。 本番環境内で問題を最速で特定するには、監視が不可欠である。 | リリースは手動でトリガーされるが、プロセス自体は自動化されている必要がある。 修正を迅速にロールバックしたり、デプロイしたりするためのオプションを引き続き検討する必要がある。 |
詳しい違いは、「継続的インテグレーション、デリバリー、デプロイの違い」ガイドでご覧ください。
継続的デプロイの現実化
インテグレーションとデプロイのプロセスが完全に手動で行われており、コードの凍結、関係者全員がテストに取り組む戦略、固唾をのんで見守るリリース日が当たり前の環境では、1 時間ごとに行われるデプロイは夢物語のように聞こえるかもしれません。
しかし、多くの組織がより定期的なこの手法に注目しているのは現実です。 Netflix、Etsy、Amazon などの大企業から知名度の低い小さな会社まで、多くの企業が継続的デプロイシステムを導入して市場と歩調を合わせる努力をしています。 この手法により、多くのソフトウェア制作会社がリリースまでの期間を数週間や数か月から数時間に短縮できています。
迅速な機能の提供とフィードバック対応へのプレッシャーが高まる中、継続的デプロイは品質を損なうことなく定期的にリリースするための戦略を提供しています。
継続的デプロイシステムの導入
継続的インテグレーションとデリバリーの延長上にある継続的デプロイは、完全に自動化されたビルド、テスト、デプロイのプロセスに依存しています。 この手法では、速度によって品質が犠牲にあることはありません。 しかし、継続的デプロイを効果的に導入するには、単なる堅固な土台以上のものが必要となります。
クオリティゲート
手動介入なしで変更をリリースできるようにするには、CI/CD プロセスを完全に信頼できている必要があります。 具体的には、自動ビルドと自動テストによってコードを効果的に検証できるようにする必要があります。 このステップでは、コードのクオリティゲートが役立ちます。
クオリティゲートは、コードがパイプラインの次のステージに進むための条件を指定する仕組みです。 あるステージでは、ユニットテストの要件を 100% の合格率と 90% のコードカバレッジとする、といった単純なしきい値を設定することができます。 他の自動テストでは、一定割合の警告を許容するものの、エラーが発生した場合にはそのステップを失敗させることもできます。 また、ステップを失敗させる前に、エラーや警告にフラグを立てて手動レビューを要求することも可能です。
パイプラインの重要なステージで自動クオリティゲートを使用することで、プロセスの制御と可視性、および各リリースで実施された適正評価の完全な監査証跡を得ることができます。
リリース戦略の検討
継続的デプロイシステムの導入方法を計画する際には、変更をどのようにリリースするかを中心に考える必要があります。 デプロイのたびにサーバーをオフラインにするとオンラインサービスに頻繫に支障が出るため、一般的にはローリングアップデート戦略が好まれています。 また、カナリアデプロイを使用して、自動テストプロセスの延長でロールアウトを実施するようにすることもできます。
カナリアデプロイ
カナリアデプロイでは更新されたコードのデプロイが少数のユーザーに限定されるため、そのユーザーが無意識に本番環境でテストをすることになります。 新しいリリースをより多くのユーザーにロールアウトする前に、ユーザーの行動と使用状況のメトリクスを監視することで、新しいリリースによって新たな問題が発生していないかを確認することができます。
カナリア信頼度スコア
会社によっては、カナリア信頼度スコアを使用してさまざまなメトリクスをベースラインと自動的に比較し、それによって自動化をさらに高度化しています。 自動ロールアウトは、このスコアが特定のしきい値を超える場合にのみ続行されます。 スコアが低すぎる場合、潜在的な問題をさらに詳しく調査するための出発点がメトリクス解析によって示されます。
ブルーグリーンビルドデプロイ
ブルーグリーンビルドデプロイプロセスは、継続的デプロイシステムを導入している組織では一般的な手法です。 ブルーグリーンデプロイは、変更が期待通りに動作すると確信を得られるまで古いコードをオンライン状態に維持しておくことで、問題発生時にリリースをロールバックしやすくするものです。 必要に応じて最初にカナリアデプロイを行い、その後にブルーグリーンロールアウトを行うことができます。
本番環境のメトリクスの監視
ブルーグリーンデプロイを実行している場合であれ、直接置き換えたものをロールアウトしている場合であれ、自動テストプロセスで捕捉されなかったバグに迅速に対応するには、本番システムの健全性を監視することが不可欠です。
まずはシステムの健全性の指標となる重要なメトリクスを特定しましょう。 たとえば、ディスク空き容量や CPU 使用率などのシステム健全性メトリクスや、リクエスト数やトランザクション数などの使用状況メトリクスなどがあります。 これらのメトリクスを健全性のベースラインと照らし合わせることで、期待通りに動作していない場合に早い段階で警告サインを得られます。 それに応じて変更をロールバックするのか、パイプラインを通じて修正を導入するのかを決めることができます。
継続的デプロイの考慮事項
CD が正しく導入されるようにするため、継続的デプロイの波に乗る前にやるべきことをいくつか検討しましょう。
関係者を関わらせる
ソフトウェア開発プロセスに伴うのは、コードの変更だけではありません。 このプロセスには、ユーザー調査、製品マーケティング、インテグレーション設計、ドキュメント、販売、法務、およびサポートといったあらゆるチームが参加しています。
関係者と一緒に土台を固めておらず、関係者と関わって関係者がリリースプロセスに求めるものを理解していない状態で自動リリースに移行しても、関係者は開発をコントロールできないと感じる可能性があります。 それでは関係者に手動チェックポイントとレビューステージを求められてしまうため、プロセスに遅れが生じ、CI/CD のメリットが損なわれてしまいます。 最悪、継続的デプロイシステムそのものが失敗した実験だと見なされ、拒否されてしまう可能性もあります。
コラボレーションを促進する
継続的デプロイをうまく機能させるには、コラボレーションの文化を育むことが不可欠です。 たとえば、開発プロセス全体にほかのチームが関与し、早い段階からデザイン、セキュリティの課題、用語、またはコンプライアンスなどの意見を考慮できれば、フィードバックループを短縮し、ソフトウェア開発ライフサイクルをより効率的に実現することができます。
常に全員に最新情報を提供する
意見を求めることと同じように、何がいつリリースされるのかを明確にすることも重要です。 CI サーバーを利用し、関係者に常に最新情報を自動的に提供しましょう。 選択した継続的ビルドデプロイツールによっては、ダッシュボードや通知によって情報を周知することも可能です。
フィーチャーフラグまたは専用ブランチを使用する
何が起きようとしているのかを明確にするだけでは不十分な場合もあります。 比較的大規模な機能に取り組んでいる場合や、リリースのタイミングを管理しようとしている場合は、コミットがすべてのテストを通過するたびに実稼働環境にデプロイするだけでは完璧ではありません。
本番環境でコードの可視性を制御するオプションの 1 つにフィーチャーフラグがあります。 コードが実際に有効になるというメリットがあるため、ソフトウェアに予期しない障害が発生していないかを監視することができます。
また、専用のブランチと本番環境に自動的にプッシュしない別のパイプラインを使用する方法もあります。ニーズに合わせて、継続的デリバリーと継続的デプロイを組み合わせて使用する方法です。
継続的デプロイのベストプラクティス
継続的デプロイは適切に行われれば、チームがバグを最小限に抑えながらユーザーへの更新の提供頻度を高めるのに役立ちます。 この鍵となるのが、メトリクスを使ったパイプラインの最適化や本番環境の障害の兆候の監視といったベストプラクティスの実践です。 それに伴う文化的な変化を認識し、チーム全体を CI/CD プロセスに関与させることも重要です。
CI/CD プロセスを合理化してより優れた成果を得る方法については、「継続的デプロイのベストプラクティス」ガイドをご覧ください。
まとめ
- 継続的デプロイは、ビルド、テスト、およびリリースプロセスの各ステージを自動化する DevOps 手法です。
- 継続的デプロイの目的は、品質を損なうことなく、機能をより迅速かつ頻繫にユーザーに提供することです。
- 継続的デプロイは、特にユーザー自身が更新を適用する必要のないウェブサイトやウェブアプリケーションに最適です。
- リリースをより迅速かつ頻繫に行えるため、ユーザーから素早くフィードバックを得られ、本番環境に潜むバグの影響を抑えることができます。
- 自動テスト、本番環境の監視、他の部門とのコラボレーション、ユーザーの行動は、すべてソフトウェア開発プロセスの情報源となります。
- より小さな部品に取り組んで頻繁にリリースすることで、フィードバックに基づいて、提供するものを継続的に調整しながら改善していくことができます。
TeamCity のメリット
TeamCity では、高度に構成可能なトリガーオプションとデプロイビルドランナーを使用して継続的デプロイのセットアッププロセスを簡単に進めることができます。 専用のデプロイビルド構成により、本番環境にデプロイできる権限を制限できる一方、柔軟なビルドトリガーによってリリースの条件を定義することができます。 TeamCity に組み込まれたパッケージリポジトリとコンテナーレジストリのサポートを利用することで、継続的デプロイプロセスの中でビルドアーティファクトを管理することができます。
関係者は TeamCity の直感的なウェブベースのダッシュボードにアクセスして情報を得ることができます。 強力なロールベースのアクセス制御により、本番環境までのパスを安全に保護することができます。また、組み込みの監査証跡機能により、パイプライン内のすべてのアクティビティに関する広範な記録を得ることができます。
