（この記事は、CloudBees社 Blog 「6 Steps to Know You’ve Hit a Home Run with Continuous Delivery」2018年3月13日 Brian Dawson 投稿の翻訳記事です。）
本当に継続的インテグレーションを実行できていますか？もしできているなら、組織のプロセスを拡張し、次のステップ、つまり継続的デリバリーのマスターにまで到達していますか？
前回のブログでは、最初の質問に焦点を当てました 。レポートや事例などから判断すると、今日ではかなりの数の企業が懸命に努力していますが、依然として継続的インテグレーションの理念のすべてに従うことには成功していないようです。
この記事では、継続的デリバリー（CD）に焦点を当てます。良いニュースとしては、組織は着実に進歩しています。悪いニュースとしては、継続的インテグレーション（CI）の場合と同じように、多くの人は、自分たちはうまくCDを行っているという錯覚をしています。
ところで、CIおよびCDとは具体的には何でしょうか？継続的インテグレーションは開発チームが行う自動化プロセスです。開発者は中央のソースリポジトリに頻繁にコードをコミットし、変更は継続的にビルドされ、検証もされます。これにより、エラーを可能な限り早期に発見して修正することができます。継続的インテグレーションの重要な原則は「フェールファスト」です。このプラクティスは開発プロセスをスピードアップし、高品質のコードを確保するのに役立ちます。
継続的デリバリーは、CIの原則とプラクティスをソフトウェアデリバリープロセスの右側（下流）に拡張します。コードを継続的にテストしてデプロイすることで、変更のたびに、ソフトウェアがリリース準備完了状態になるようにします。継続的デリバリーにより、変更は迅速かつ再現性があり信頼性の高い方法で、運用前の環境や運用環境に、そして最終的にはユーザーの手に渡すことができます。CIと同様に、これにより、現実的なフィードバックに基づいて「フェールファスト」し、顧客に提供する価値を向上させることができます。
強く推奨されるCDの定義に従い、継続的デリバリーを本当に実践するには、次の3つの質問に「はい」と答えることができなければなりません。
- すべての変更のたびにソフトウェアはリリース準備完了状態になっていますか？
つまり、いつでも自分のソフトウェアを本番環境にデプロイできるでしょうか。 - ソフトウェアがリリース可能かどうかをすべての関係者が把握していますか？
つまり、プロセスは自動化され、繰り返し可能であり、追跡可能でしょうか。 - いつでも「ボタンを押すだけ」でデプロイを実行できますか？
つまり、ソフトウェアのデプロイと設定は自動化され、繰り返し可能でしょうか。
最近、業界で継続的デリバリーが注目を集めていることもあり、大多数の企業がすでにベストプラクティスを完全かつ正確に実装しているように思われるかもしれません。継続的デリバリーという用語はJez HumbleとDave Farleyが2010に出した書籍『 Continuous Delivery』によってを有名になり、NetflixやFlickrのような最先端のテクノロジー企業は、1時間に何十回ものデリバリーを実現する方法を世界に知らしめました。
しかし、数字は別の話を伝えています。DZone 2016 Guide to Continuous Deliveryによると、調査対象の半数は、自分たちは継続的デリバリーのプラクティスに従っていると考えていましたが、3つの基準に基づいて判定すると、実際に実践できているのはわずか10％でした（これでも、2014年の8％からは改善されています）。
第1に、端的に言って、ソフトウェアが常にリリース可能状態にあることが保証されている場合、ほぼ確実に継続的デリバリーが行われています。
上記の第2の基準ーソフトウェアがリリース可能かどうかをすべての関係者が知っていることーこれは絶対的な条件ではありませんが、重要です。ソフトウェアのビルド、テスト、測定、そしてデリバリーが継続的に行われている場合は、この条件は、それほど重要ではないかもしれません。しかし、このような可視性は、プロセスの自動化を可能にするDevとOps間の信頼を確立するためには不可欠であることが多いでしょう。可視性の共有は、フィードバックループも強化します。
第3の定義 – いつでも「ボタンを押すだけ」でデプロイ可能かどうかは、デプロイメントは日常的な処理でなければならないというCD原則に基づいています。これは、ソフトウェアが常にリリース準備完了状態にあり、運用環境およびデプロイメントプロセスでテスト済みであることを意味します。
継続的デリバリーは、上記の基準によって簡潔に定義され、多くの著作でも詳細に説明されていますが、継続的デリバリーを正しく実装するための基本的なステップとはどのようなものでしょうか？
ここでは、本当に継続的デリバリーを行えているかを評価する6つのステップをリストします。
- 変更を適切なサイズにする
最初に行うべきタスクの1つは、継続的デリバリーパイプラインを通じて迅速にデリバリーし、テスト自動化をサポートし、リスクを最小限に抑えられるような大きさで変更やユーザーストーリーを表現することです。これにより、リスクを抑制しながら、簡単に統合、テスト、デプロイすることができます。また、必然的に、顧客に提供される付加価値という観点から思考するようになります。これを実現するには、ウォーターフォール型開発プロセスから、かんばんやスクラムなどのリーンまたはアジャイルの方法に移行します。 - トラッキングシステムを使用する
継続的デリバリーでは、システム内の変化の移動を追跡する能力が重要です。BugzillaやJiraのようなトラッカーを使用すると、関係者はデリバリープロセス全体でコラボレーションし、変更のサイクルタイムなどの重要業績評価指標（KPI）を測定できます。 - バージョン管理システムを実装する
トラッカーを使用すると、変更を登録し、パイプラインのどこに変更があるかを追跡できます。同時に、トラッカーシステムに登録された変更は、最終的に開発チームによって行われたコード変更を表します。バージョン管理システムを使用すると、チームはいつでもコードの何が変更されたかを把握し、迅速にロールバックすることができます。Gitなどの最新のバージョン管理システムには、プルリクエストなどのコラボレーション機能があります。プルリクエストは、ピアレビューを義務付けることによって品質を向上させます。 - ビルドを自動的にデプロイする
ビルドを下流に送るには、ビルドが実際に実行される環境と同様の環境にビルドを自動的にデプロイできることが重要です。ここでの重要な側面は、デプロイの機能だけでなく、デプロイ先のインフラストラクチャや環境へのアクセスも提供することです。従来のプロセスでは、デプロイは静的でした。継続的デリバリーパイプラインでは、変更が速いペースでデリバリーされるため、すぐに、そして継続的に環境にアクセスできることが必要になります。 - 運用環境と同様の環境にデプロイする
パイプラインのできるだけ早い段階で、運用環境と同等の環境にアクセスできなければなりません。開発時からアクセスできるのが理想的です。これは重要なことです。なぜなら、継続的デリバリーの目標は、右方向へのシフトと問題の早期発見だからです。本番とは異なる環境にソフトウェアをデプロイしている場合、いざ本番環境にデプロイするときに、必ず未知の要素があります。したがって、ソフトウェアが常にリリース準備完了状態にあるとは主張できません。この問題を解決する方法の1つは、コードとしてのインフラストラクチャ(Infrastructure as Code)または構成管理ソリューションを使用して本番環境を定義し、その構成を使用して、開発、テスト、およびステージのためのプリプロダクション環境を定義することです。 - 一度だけビルドし、バイナリをプロモートする
私が協力している企業のうち、CDを実践していると主張しているところの多くは、複数のチームや環境にまたがってソースコードをプロモートし、それぞれのステージでソフトウェアを再ビルドしています。これはよくあるCDのアンチパターンです。ソースコードを再ビルドするたびに、エラーが混入する可能性、そしてエラーが見過ごされる可能性が高くなります。ビルドスクリプトや環境などに違いが含まれる可能性があるので、上流で行ったテストや検証は信頼できません。適切なアプローチは、一度だけビルドしてバイナリをプロモートすることです。これにより、下流のステップは、前のステップで作成された信頼のおけるリリースに基づいてビルドできます。
まとめ
継続的インテグレーションは、継続的デリバリーの前段階です。CIやCDを正しく実行していない企業は、これらのプロセスがもたらすビジネス価値を得ることはできません。その価値とは、市場投入時間の短縮、競争優位性の向上、ソフトウェア品質の向上、従業員の満足度の向上です。