継続的デリバリーとは？

DevOpsでは、意識の移行が中心としてあります。 ソフトウェア開発プロセスを、チームからチームにハンドオフされる要件、コード、レポートを載せた一方通行のコンベアベルトとして線形的に捉えるのではなく、DevOpsでは、短いインタラクティブなサイクルから得られるコラボレーションと迅速なフィードバックが重要となります。

「完了」の定義を変えてみれば、この考え方を受け入れやすくなるでしょう。プロセスチェーンの次のチームにコードを送った時点で「自分の担当タスクは終了した」と考えるのではなく、自分の作った新しい機能や変更したコードがライブとしてリリースされた時点でのみ「終了した」とするのです。 このパイプラインのどこかの段階で問題が見つかれば、そのフィードバックを迅速に伝達し合って共同的に修正に取り組めば、長々としたレポートを変更委員会の承認に通さなければならないプロセスよりも素早く解決に持ち込むことができます。 これが継続的デリバリーの本分です。

ソフトウェア開発ライフサイクルのほんの一部ではなく、全体を眺めてみると、ユーザーにソフトウェアを提供するために必要なタスクをより明確に把握できるようになり、関係するほかのチームとのコミュニケーション手段を増やす機会が見えてくるでしょう。

継続的デリバリーでは、より迅速かつ確実なリリースを実現できるように、このデリバリープロセスを減速させるネックとなっている部分を特定してパイプラインの自動化を図ることで、いつでもリリースする準備を整えておかなければなりません。 パイプラインが整っていれば、コマンドを1つ送るだけで、リリースできるビルドをライブにすることができるのです。

継続的インテグレーションはこの基盤といえます。コード変更が少なくとも毎日コミットされ、その後には、開発者にフィードバックを迅速にフィードバックするためのビルドプロセスとテストプロセスが続きます。 ビルドまたはテストに失敗した場合、それを対処することが全員のプライオリティとなります。

バグを早期に検出できれば、意識の中でコードの鮮度が高いうちに修正することができるため、ほかの機能をバグのあるコード上に構築せずに済み、後々取りこぼす可能性がなくなります。 継続的デリバリーを採り入れることで、継続的インテグレーション（CI）プロセスからの最新の変更が含まれたビルドを、本番前環境を通じて自動的に公開することができます。 本番への最終的なプッシュは手動で行われることになりますが、それもスクリプト化されたプロセスで行われるため、繰り返して行うことが簡単であり、必要に応じていくらでもリリースできるようになります。

CI/CDパイプラインの構築は、リリースプロセス内の様々な関係者が共同して取り組む機会を生み出します。そこで、パイプラインの設計には、そういった関係者のニーズを組み入れる必要があります。 自動テストを設計する際に、QA担当者と協力したことがあったことでしょう。

手動による探索的テストの段階を適切なテスト環境（できる限り本番環境に近い環境）に追加することで、予測していなかった問題を特定できるようにもなります（この問題は自動テストで対応できるようにすることができます）。 継続的デリバリーの重要なステップです。

セキュリティ監査の実行とその後の長いレポート作成処理に時間のかかる情報セキュリティまたはサイバーセキュリティチームは、頻繁なリリースの障害としてみなされることがほとんどです。 これは、DevSecOpsのアプローチを採ることで、セキュリティ要件をパイプラインに織り込みやすくなります。

必要となる実際のビルドステップ、環境、およびテストは、利用しているソフトウェアのアーキテクチャや組織の優先順位によって異なります。 マイクロサービスに基づくシステムを構築している場合は、より複雑なインテグレーションやエンドツーエンドテスト向けにサービスをひとまとめにする前に、サービスごとに並行してテストを実施できるアーキテクチャを活用することができます。

パイプラインを通じて行われるバグ修正に対する手動の探索的テストがネックとなるように感じられるかもしれませんが、この場合は、変更の種類に応じたオプションのステップまたは別のパイプラインを用意しておくことで、継続的デリバリーをより効率的に進められるでしょう。

パイプラインのステージと各ステージで実行されるテストを決定したら、確実に繰り返して利用できるように、プロセスをスクリプト化しましょう。 一貫性に欠くことのないように、CIステージからの同一のビルドアーティファクトを本番前の各環境と本番環境にデプロイしてください。

理想的には、新しいビルドを使用するたびにテスト環境を新規にすることをお勧めします。また、コンテナをIaC（Infrastructure as Code）アプローチで使用すれば、このステップをスクリプト化でき、必要に応じて新しい環境を壊したりスピンアップしたりすることができます。

サポート、営業、またはマーケティングチームが新しい機能に慣れるために使用するステージング環境がパイプラインに含まれている場合は、進行中の作業を中断せずに済むように、手動で新しいビルドを導入するほうがよい場合もあります。 最終リリースを公開する時と同じように、新しいビルドの導入プロセスを高速化し、一貫性を維持するために、そのデプロイメントをスクリプト化することができます。

継続的デリバリーでは、品質を妥協することなくリリースを加速化することが約束されますが、それを実現させるには、組織内の多くの部門の協力が必要となります。

サイロを切り崩すことは、短期的な課題でありつつも、コラボレーションによって作業の効率性がアップするため長期的なメリットと言えます。

継続的デリバリーの実装には時間を掛ける必要があり、気が重く感じられるかもしれません。 インタラクティブなアプローチを取り、時間を掛けてプロセスを構築すれば、取り組みやすくなりますし、上級関係者にそのメリットを証明できるようになるでしょう。 ビルドやテスト時間に関するメトリクスを収集し、手動プロセスのメトリクスと比較することで、投資利益率だけでなく不良率を簡単に証明できます。

継続的デリバリーの価値を測定すると、インフラストラクチャの要件を計画する際に役立ちます。 リリースプロセスをスケールアップするにつれ、複数のビルドとテストを並行して実行し始めるようになるため、マシンの可用性が制限の要因となる可能性があります。 パイプラインのパフォーマンスを最適化したら、必要に応じてスケールできるクラウドホスティング型インフラストラクチャに移行することを検討すると良いでしょう。

CI/CD パイプラインの構築は、最初の段階でチームからの大量のインプットが必要になる面倒な作業に思えるかもしれません。 しかし、CI/CD パイプラインを適切に構築すれば、ソフトウェアデリバリープロセスにかかる時間を 10 分の 1 に短縮できます。 ただし、プロセスを正しくセットアップするには、いくつかの CD のベストプラクティスに従うことが重要です。

継続的デリバリーは、ソフトウェアを本番環境に出荷するのに必要な各種のステップを自動化するプロセスです。 とは言え、ソフトウェアのリリースを完全に自動化する必要はありません。ここで継続的デプロイが役に立ちます。 継続的デリバリーと継続的デプロイは、同一の CI/CD プロセス内で異なる役割を果たしていると考えることができます。

継続的デリバリーと継続的デプロイの比較に関する詳細

継続的デリバリーは、ソフトウェアのリリースをより簡単かつ迅速に行うための手法で、これまでよりもさらに頻繁に本番へのデプロイメントが可能になります。 大規模な四半期または1年ごとにリリースするのではなく、より規模の小さな更新を頻繁に提供するのです。 こうすることで、ユーザーに新機能やバグ修正を提供するまでの期間を短縮できるだけでなく、開発したソフトウェアが実際の現場でどのように使用されているのかを観察し、適宜に計画を調整できるようになります。

組織によっては、リリースプロセスの最終ステップをこれまでどおり制御することを好むでしょうが、理論的な結論として、CI/CDパイプラインは、継続的デプロイメントという手法でリリースを公開するプロセスを自動化することだと言ってよいでしょう。