継続的デプロイメント（CD）とは？

インテグレーションとデプロイメントのプロセスを完全に手動で行い、コードの凍結、関係者全員が最優先で関与するテスト戦略、会社全体が息をのんで見守るリリース日が当たり前となっている場合は、毎時間、当然のごとく行われるデプロイメントは夢物語のように聞こえるかもしれません。

しかし、NetflixやEtsy、Amazonから、市場との足踏みを揃えようと努力しているより小規模の会社まで、多数の組織がこのアプローチに転換しつつあるのが現実です。 そして継続的デプロイシステムの採用によって、リリース時間を数週間や数か月から数時間へと短縮することができています。 業界が拡大する中、機能の素早い公開とフィードバックへの迅速な対応が不可欠となっています。

継続的インテグレーションとデリバリーの延長線に置かれる継続的デプロイは、完全に自動化されたテストとビルドのデプロイメントのプロセスに依存しながら、速度によって品質が損なわれないようにしています。 しかし、継続的デプロイを効果的に実装するには、その確立した基礎以上のものが必要となります。

継続的デプロイシステムをどのように実装するか計画する際には、変更をどのようにリリースするのかということを中心に考える必要があります。 オンラインサービスの頻繁な中断を避けるために、サーバーをオフラインにせずに更新をロールアウトする方法を選択するほか、ロールアウト機能を自動テストツールの拡張機能にすることも可能です。

カナリアデプロイメントでは、更新されたコードのデプロイメントを本番環境でテスターであることに無意識な少数のユーザーに制限することができます。 新しいリリースをより多数のユーザーにロールアウトする前に、テスターの行動と使用状況のメトリクスを監視することで、新しいリリースが新たな障害を引き起こしていないかを確認することができます。

一部の会社では、カナリア信頼スコアという、メトリクス全体を自動的にベースラインに比較する仕組みを用いて、自動化をさらに高度化しています。 ロールアウトは、このスコアが特定のしきい値を超えた場合にのみ自動的に行われ、その間、メトリクス解析から、潜在的な課題をさらに調査するための開始点を得ています。

ブルーグリーンビルドデプロイプロセスは、継続的デプロイを実装している組織に共通する手法です。このプロセスでは、変更が期待通りに動作する確信を得られるまで古いコードをオンライン状態に維持しておくことで、問題が発生した場合に、リリースをより簡単にロールバックすることができます。 必要であれば、最初にカナリアデプロイメント行って、ブルーグリーンロールアウトを使用することができます。

ブルーグリーンデプロイメント実行しているのか、直接入れ替えをロールアウトしているのかに関係なく、リリースプロセスで拾われなかったバグに迅速に対応するには、本番システムの健全性を監視することが不可欠です。

ディスクの空き容量やCPU使用率からリクエスト数やトランザクション数に至るまで、システムの健全性を示す特定のメトリクスを観察し、それらをベースラインと比較することで、早い段階で、何かが予想外の動作を起こす際の警告を読み取ることができます。 その上で、変更をロールバックするのか、パイプラインを通じて修正を提供してロールアウトするのかを決定することができます。

継続的デプロイの流行に便乗する前に、通常、CDを採用したときに突然現れるいくつかの課題について検討することをお勧めします。

ソフトウェア開発プロセスに伴うのは、コード変更だけではありません。 このプロセスには、ユーザー調査、製品マーケティング、インテグレーション設計、ドキュメント、販売、法務、およびサポートといったあらゆるチームが加担しています。

関係者と土台を固め、リリースプロセスから何を引き出そうとしているのかを理解し合っていなければ、継続的デプロイに移行しても、開発が手に余ると感じられてしまいかねません。 そうなると、手動チェックポイントやレビューステージが導入されて、プロセスの進行が遅れたり、継続的デプロイシステム全体は失敗として却下されることになったりするでしょう。

コラボレーションのカルチャを作り出す必要があります。 たとえば、開発プロセス全体にほかのチームが関与し、早い段階からデザイン、セキュリティの課題、用語、またはコンプライアンスなどの意見を考慮できれば、フィードバックループを短縮し、ソフトウェア開発ライフサイクルをより効率的に実現することができます。 意見を求めることと同じように、何がいつリリースされるのかという可視性が計画にあることも重要です。 関係者への情報提供は、継続的ビルドデプロイツールである CI サーバーを使ってダッシュボードや通知によって自動的に行うことができます。

何が起きようとしているのかに対する可視性があるだけでは、不十分であることもあります。 より大型の機能を作成している場合や、リリースのタイミングを管理しようとしている場合には、コミットがすべてのテストに合格するたびにライブにデプロイするだけでは理想的と言えません。

本番でコードの可視性を管理するには、一例として、機能フラグを使用することができます。コードがライブであることを利用し、予測されなかった障害が発生しないかを監視することができます。 また、本番に自動的にプッシュしない別のパイプラインにデプロイされた専用のブランチを使用する方法もあります。ニーズに合わせて、継続的デリバリーと継続的デプロイを組み合わせて使用する方法です。

継続的デプロイを適切に実行すれば、チームがユーザーへのソフトウェアデプロイを自動化するのを支援できます。 継続的デプロイのベストプラクティスに従うと、プロセスを合理化し、より良い結果を得られます。 たとえば、パイプラインを定期的に監視し、何らかの障害の兆しがないかを判断することが重要です。 また、チーム全体で効果的な CI/CD パイプラインの構築に取り組むことも合理的と言えます。

この 2 つは混同しやすいものですが、継続的デプロイと継続的デリバリーは、いずれも CI/CD パイプラインの CD 側にある異なる部分です。 While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.

継続的デプロイは、品質を損なうことなく機能をユーザーに素早く提供するために、自動化を最大限に使用しています。 このDevOps手法には、定期的で迅速なフィードバックが不可欠です。 ソフトウェア開発プロセスは、自動テスト、本番モニタリング、ほかの役職とのコラボレーション、ユーザーの行動から情報を得ており、 より小さな部品に取り組んで頻繁にリリースすることで、フィードバックに基づいて、提供するものを継続的に調整しながら改善していくことができます。