継続的デリバリーを理解しよう

継続的デリバリー（CD）は、継続的インテグレーション（CI）に基づいてソフトウェアの本番環境へのリリースを準備する際に必要なステップを自動化する手法です。

コード変更を指定のブランチにマージするたびに継続的インテグレーションのプロセスによって自動ユニットテストなどの一連のチェックが実行され、ビルドが作成されます。 継続的デリバリーはこのプロセスをさらに拡張し、一連のテスト環境とステージング環境に各ビルドを自動的にデプロイした後、さらなる自動テストを実行します。

このような自動テストには、統合テスト、UI テスト、パフォーマンステスト（負荷、ソーク、ストレステストなど）、およびエンドツーエンドテストが含まれる場合があります。 業界によっては、継続的デリバリーを使用してセキュリティテスト、アクセシビリティテスト、および手動のユーザー受け入れテストや探索的テストも実行する場合があります。 ビルドは各ステージを正常に合格すると、本番環境へのリリースできる状態になったと見なされます。

継続的インテグレーションと同様、継続的デリバリーを効果的に実践するには、可能な限り多くのプロセスを自動化するのが重要です。 このようなプロセスには、各ステージに対するフィードバックを提供することや、ビルドがステージを合格できなかった場合にチームに警告して迅速に問題に対処できるようにすることなどが挙げられます。

継続的デリバリーと継続的デプロイは、どちらも自動的に環境にビルドをデプロイして自動テストを実行する処理が伴います。 そのため、これら 2 つの用語は同義的に使用されることがありますが、 継続的デリバリーと継続的デプロイには立派な違いがあります。

継続的デプロイの場合、コード変更は各テストステージを正常に合格するたびに自動的に本番環境にデプロイされます。 これに対し、継続的デリバリーの場合はソフトウェアを本番環境にリリースする最終ステージに手動のステップが伴います。

継続的デプロイはあらゆるソフトウェア開発チームが理想とする目標のように聞こえるかもしれませんが、継続的デリバリーを実践しないことを選択するチームが多数存在するのにはそれなりの理由があります。

継続的デリバリーと継続的デプロイの比較に関する詳細をお読みください。

CI/CD プロセスの最後のステージには、本番環境へコードの変更をデプロイする処理が伴います。 継続的デリバリーの場合、本番環境へのリリースプロセス自体は自動であっても、リリースの決定は手動のステップです。

継続デリバリーを継続的デプロイに拡張するための足掛かりとして実践するチームもあります。 本番環境への最終デプロイを手動で行うことは、自動テストとチェックに信頼を置けるようになるまでの安全策になるためです。 このような場合、すべての正常なコードの変更を本番環境に自動的にデプロイする前に数か月ほど継続的デリバリーを実践するのが良いでしょう。

ただし、ソフトウェアの更新を 1 日または 1 時間ごとに数回デプロイするのは必ずしも最善の選択とは言えません。 モバイルアプリ、API、組み込みソフトウェア、デスクトップ製品などのバージョン管理されたソフトウェアの場合、変更をより大きなリリースにまとめる方が合理的な場合も少なくありません。 インストールされている製品のユーザーは数時間ごとにアプリの更新を要求されることを想定していませんが、新しい API のバージョンにアップグレードした場合は顧客に著しい影響が出る可能性があります。 継続的デリバリーと継続的デプロイのどちらにするかを決める場合は、ビジネスとユーザーにとって適切な判断を下すことが重要です。

実際のビルドステップ、環境、およびテストは取り扱う製品や組織によって異なるものの、継続的デリバリープロセスは以下の一般的な原則に従って構築することができます。

• CI から始める: ほとんどの場合、継続的デリバリーの前に継続的インテグレーションを導入するのが合理的です。 CI は主に開発チームに影響するものであるため、外部関係者が関与する前に、ビルド、テスト、およびデプロイプロセスの自動化に慣れる機会を得ることができます。
• 迅速なフィードバックを得られるように CD プロセスをデザインする: 問題を早期発見することで、開発プロセスの効率が高まります。 複数の異なるプラットフォームのビルドに対する自動 UI テストなど、一部のステージは同時実行可能です。 同様に、実行時間の長いテストやリソースを激しく消費するパフォーマンステストは、ビルドが前のステージを正常に合格するまで後回しにできます。
• 関係者に関与を求める: CI/CD の背後にある DevOps の哲学によって複数の開発チームがお互いの壁をなくし、ソフトウェア開発プロセス全体を考慮することが促進されます。 CD パイプラインを設計する際には、運営、セキュリティ、マーケティング、サポートに至るまで、現在のリリースプロセスに参加するあらゆる担当者を関与させてください。
• テストを自動化する: 自動テストはソフトウェアが意図通りに動作することを確実かつ迅速に検証可能にするため、継続的デリバリーには欠かせません。 自動テストが準備されていない場合は影響が最も大きな部分を優先し、徐々にテストカバレッジを上げていくと良いでしょう。
• 同じビルドアーティファクトを再利用する: 不整合の発生を避けるには、CI ステージの同じビルドアーティファクトをすべての本番前環境と本番環境自体にデプロイしましょう。
• テスト環境を自動的にリフレッシュする: 理想的には、テスト環境は CI/CD プロセスの中で新しくビルドを行うたびにリフレッシュすべきです。 コンテナーとインフラストラクチャのコード化手法を採用すると、必要に応じて環境を破棄し、新しい環境を起動するのがより容易になります。
• 関係者のニーズを考慮する: 前のポイントの例外としては、サポート、営業、またはマーケティングチームが新機能に慣れるために使用するステージング環境が挙げられます。 これらのチームでは、進行中の作業を妨げないように要望に応じて環境を更新する方が望ましい場合があります。
• DevSecOps を採用する: 情報セキュリティまたはサイバーセキュリティチームはセキュリティ監査やその後のレポート作成の実行に時間を要するため、リリースの妨げになっていると見なされがちです。 DevSecOps の手法を採用し、セキュリティ要件を最初からパイプラインに組み込むことをお勧めします。
• 手動テストの要件を検討する: ビジネスによっては手動の探索的テストを組み込み、予期しない障害モードを特定するのに役立ててください。 コードが変更されるたびに手動テストを要求するのではなく、省略可能なステップや毎週または毎月実行される代替パイプラインを用意することを検討してください。
• リリースを自動化する: 継続的デリバリーでは本番環境へのリリースは手動で決定され、リリース自体は自動で行われます。 コマンドを 1 つ送るだけで、リリース可能なビルドを本番にデプロイすることができます。

継続的デリバリーを採用したチームはソフトウェアのリリースをより迅速かつ頻繫に行いながら、本番環境に入り込むバグの数を減らすことができます。 これを達成するには、継続的に変更をテストして検出された問題をすぐに解決することにより、常にコードをリリース可能な状態に維持することが重要です。

また、継続的デリバリーによって次のような複数のメリットも得ることができます。

• リリース頻度が上がることにより、開発期間が短縮され、新機能、修正、機能強化をより素早くユーザーに提供できるようになります。
• 継続的テストプロセスにより、作業内容に対する迅速なフィードバックを得られます。 最近の変更によって脆弱性が生じたり、特定の状況でアプリがハングしたり、API の呼び出しが失敗したりする場合、従来のリリーステストプロセスよりもはるかに早い段階でそれらを把握することができます。
• 問題をより早期に発見することで、より効率的な開発プロセスが実現します。 変更内容がまだ記憶に新しいだけでなく、欠陥のあるコードに依存している他のコードへの変更が追加されるリスクも減ります。
• 繰り返される定型的なビルド、テスト、リリースのタスクを自動化することで、それらの実行の一貫性を保ち、ミスを起こすリスクを軽減しながら、チームメンバーを付加価値のある他のタスクに専念させることができます。
• 自動テストに投資することで、ソフトウェアをより徹底的にテストできるようになります。 自動テストには、複数のプラットフォーム間で一貫したテスト、アクセシビリティ要件の遵守のチェック、製品またはサービスのパフォーマンスの基準確立などが含まれる場合があります。
• 環境を自動的にリフレッシュしてビルドをデプロイすると、オンプレミスサーバーでもクラウドホスティング型のビルドファームでもインフラストラクチャをより効率的に使用できるようになります。
• ステージングサイトへのデプロイを自動化すると、開発または運営チームは特に手動操作を行わなくても、プロダクト、マーケティング、およびサポートチームが新機能をプレビューできるようになります。
• 継続的デリバリーによって、リリースプロセスの堅牢性と再現性が高まり、リリース日時を正確に制御できるようになります。 CD プロセスが用意されていれば、小さな改善を毎週、毎日、または毎時間反映させるようにすることができます。

継続的デリバリープロセスの導入には、いくつかの課題が伴う場合があります。

• チーム間の連携: 運営、インフラストラクチャ、セキュリティチームなど、組織内の複数チームからの協力が必要となる可能性が高くなります。 このようなチーム間の壁をなくすのは短期的には難しい可能性がありますが、長期的にはコラボレーションの改善と有効性につながります。
• 時間への投資: ビルド、テスト、およびリリースプロセスの自動化には時間がかかります。 ただし、反復的な手法で時間をかけてプロセスを構築すると、このような状況に対応しやすくなります。 欠陥率やビルド時間といったメトリクスを収集し、それらを手動で行った場合と比較することで、関係者に効果的に投資収益率を示すことができます。
• 拡張の課題: 継続的デリバリープロセスを拡張する際には、複数のビルドとテストを同時実行することを考えるようになるでしょう。 この時点では、利用できるサーバーの数が制限の要因となる可能性があります。 パイプラインのパフォーマンスを最適化したら、必要に応じてビルドファームを拡張できるクラウドホスティング型インフラストラクチャに移行することを検討してください。

継続的デリバリープロセスの構築は面倒に思えるかもしれませんが、正しく行えば、バグの数を最小限に抑えながら、ソフトウェアのリリース速度を大幅に向上させることができます。

継続的デリバリーを効果的に導入するには、主に DevOps の考え方を採用する必要があります。 DevOps ではソフトウェアの開発プロセスをチームからチームに受け渡される要件、コード、レポートを載せた一方通行のベルトコンベアとして見なす代わりに、短期間の反復的なサイクルから得られるコラボレーションと迅速なフィードバックが重要となります。

「完了の定義」を変えると、この考え方を採用しやすくなります。 コードをテストに受け渡した時点をタスクの完了とするのではなく、新しい機能またはコードの変更が本番にリリースされた時に初めて完了とするのです。 このパイプラインのどこかの段階で問題が見つかった場合、そのフィードバックを迅速に伝達し合いながら共に修正に取り組むことで、長々としたレポートを変更委員会の承認に通さなければならないプロセスよりも迅速に解決に持ち込むことができます。 これが継続的デリバリーの本質です。

継続的デリバリーの導入を開始するのに役立つその他のヒントについては、CI/CD ベストプラクティスガイドをご覧ください。

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

リリースプロセスの最終ステップを従来通りに制御することを好む組織もあれば、CI/CD パイプラインを継続的デプロイという手法で本番へのリリースを自動化することを必然的に結論とする組織もあります。 これについては、CI/CD ガイドの次のセクションで詳しくご覧ください。

TeamCity は、さまざまなビルドツール、テストフレームワーク、コンテナー、およびクラウドインフラストラクチャプロバイダーを幅広くサポートする CI/CD プラットフォームです。 ビルドマシンをオンサイトでホストする場合でも、クラウドにホストする場合でも、両方を組み合わせて使用する場合でも、TeamCity はビルドタスクを調整し、最大限の効率を引き出します。

TeamCity のカスタマイズ可能なパイプラインロジックにより、複数の異なるプラットフォームに対するテストなどのプロセスを同時に実行するタイミングや、次のステージに進む前に正常な完了を要求するタイミングを選択できます。 作業場所を問わず、構成可能な通知によって必要な情報を得られるため、不要な中断を避けることができます。 最後に付け加えますが、詳細な結果を得られるため、本番環境までの過程を明確にできます。