継続的デリバリーパイプラインの基礎

決まり文句のように聞こえるかもしれませんが、「過つは人の常」という言葉は今でも当てはまります。チームは手動リリース時の影響に備えて気を引き締めます。なぜなら、それらのプロセスが脆弱であるためです。予測性とは、リリースが継続的なデリバリー パイプラインを介して行われる場合、リリースは本質的には決定論的であることを意味します。パイプラインはプログラム可能なインフラストラクチャであるため、チームは毎回望ましい動作を期待できます。もちろんバグのないソフトウェアはないため、アクシデントが発生する可能性があります。しかし、パイプラインは手動エラーが発生しやすいリリース プロセスよりも飛躍的に優れています。その理由は、パイプラインは人間とは異なり、厳しい期限の下でも行き詰らないからです。

パイプラインにはアーティファクトのバージョンの通過を自動的に促進または拒否するソフトウェアゲートがあります。リリースプロトコルが認められない場合は、ソフトウェアゲートは開かず、パイプラインは中断されます。警告が生成され、パイプラインを破損させた可能性のあるチームメンバーを含んだ配信リストに通知が送信されます。

これが CD パイプラインの仕組みです。パイプラインが正常に実行されるたびに、コミット、または小さく分割したバッチのコミットが本番環境に進みます。最終的にチームは安全で監査可能な方法で機能 (最終的には製品) をリリースします。

パイプラインを流れる製品のアーキテクチャは、継続的デリバリーパイプラインの構造を決定する重要な要素です。高度に結合された製品アーキテクチャは複雑なグラフィックパイプラインパターンを生成し、さまざまなパイプラインが絡みあい、最終的な製品化に向かいます。

また、製品のアーキテクチャはパイプラインのさまざまなフェーズに影響を与え、各フェーズで生成されるアーティファクトにも影響します。継続的デリバリーの 4 つの一般的なフェーズを説明します。

1. コンポーネント フェーズ
2. サブシステムフェーズ
3. システムフェーズ
4. 本番フェーズ

組織内で 4 つを超えるフェーズまたは 4 つに満たないフェーズを予測している場合でも、以下に説明する概念が適用されます。

よくある誤解は、これらのフェーズがパイプラインで物理的に出現するというものです。そうとは限りません。これらは論理的なフェーズであり、テスト、ステージング、本番といった環境マイルストーンにマッピングできます。たとえば、コンポーネントやサブシステムは、テスト環境でビルド、テスト、デプロイできます。サブシステムまたはシステムは、ステージング環境で組み立て、テスト、デプロイできます。サブシステムまたはシステムを、本番フェーズの一環として本番環境に進める場合があります。

欠陥から生じるコストは、テスト環境で見つかった場合は低く、ステージング環境で見つかった場合は中程度となり、本番環境で見つかった場合は高くなります。「シフト レフト」とは、検証をパイプラインの早い段階に前倒しすることを指します。今日、テスト環境からステージング環境へのゲートには以前よりもはるかに多くの防御的技術が施されているため、ステージング環境が犯罪現場のようになることはありません。

従来、情報セキュリティ チームは ソフトウェア開発ライフサイクルの最後に、拒否されたリリースが会社のサイバーセキュリティへ脅威を招く可能性がある時にやってくるのが常でした。志は立派ですが、フラストレーションと遅延を招いていたのも事実です。「DevSecOps」とは、完成した (恐らく安全でない) 製品を評価に送るのではなく、設計フェーズから製品にセキュリティ対策を組み込むという考え方です。

継続的なデリバリーのワークフロー内で「シフト レフト」と「DevSecOps」に取り組む方法を詳しく見てみましょう。ここから先のセクションでは、それぞれのフェーズを詳述します。

パイプラインは、最初にコンポーネント、つまり配布可能でテスト可能な製品の最小単位を構築します。たとえば、パイプラインによって構築されたライブラリはコンポーネントと呼べます。コンポーネントはとりわけ、コード レビュー、ユニット テスト、静的コード分析ツールによって認定を受けられます。

コード レビューは、製品の稼働を開始するのに必要な機能、テスト、インフラストラクチャについての理解をチームが共有するという意味で重要です。多くの場合、他者の視点はとても効果的です。長い年月の間に不適切なコードに対して免疫ができ、もはや不適切だと感じなくなってしまうことがあります。新たな視点によってそれらの脆弱性を再検討することを余儀なくされ、必要な場面で惜しみなくリファクタリングを行うことができます。

単体テストは、ほとんどの場合、コードに対して最初に実施されるソフトウェア テストです。ネットワークやデータベースをテストすることはありません。コード カバレッジは、単体テストが実施されたコードの割合です。カバレッジには、行カバレッジ、クラス カバレッジ、メソッド カバレッジなど、複数の測定方法があります。

優れたコード カバレッジを達成してリファクタリングを容易にするのは素晴らしいことですが、高いカバレッジの目標値を強制することは有害です。予想に反し、コード カバレッジの低いチームよりも、コード カバレッジの高いチームの方で本番での停止が多く発生する場合があります。また、カバレッジの数値は簡単に操作できることも覚えておく必要があります。特に性能レビューなどの重大なプレッシャーの下で、開発者はコード カバレッジを高めるために不公正な手法に転じてしまう場合があります。詳細についてはここでは触れないでおきます。

静的コード分析は、コードを実行せずにコード内の問題を検出します。問題を検出するための安価な方法であり、ユニット テストと同様、これらのテストはソース コード上で短時間で実行されます。静的分析ツールは循環的複雑度やコードの重複などのコード品質インジケーターとともに、潜在的なメモリ リークを検出します。このフェーズにおいて、静的解析セキュリティ テスト (SAST) はセキュリティの脆弱性を発見するための実証済みの方法です。

ソフトウェアのゲートを制御する指標を定義し、コンポーネント フェーズからサブシステム フェーズへのコードの昇格に影響を与えます。

ゆるく結合したコンポーネントがサブシステムを構成します。サブシステムはデプロイおよび実行可能な最小単位です。たとえば、サーバーはサブシステムです。コンテナで実行されるマイクロサービスもサブシステムの一例です。コンポーネントとは異なり、サブシステムは顧客のユースケースに対して立ち上げ検証できます。

Nod.js と同様、UI や Java API 階層もサブシステムであり、データベースもサブシステムです。データベースの変更管理を自動化し、データベースの継続的デリバリーを正常に行う新世代のツールが出現したにも関わらず、一部の組織では RDBMS (リレーショナルデータベース管理システム) を手動で処理しています。NoSQL データベースを含む CD パイプラインの方が RDBMS よりも簡単に実装できます。

サブシステムは、機能テスト、パフォーマンス テスト、セキュリティ テストによってデプロイして認定できます。これらのテスト タイプがどのように製品を検証するかを確認してみましょう。

機能テストには、国際化 (I18N)、地域化 (L10N)、データ品質、アクセシビリティ、負のシナリオなどを含む顧客のあらゆるユースケースが含まれます。これらのテストは、製品が顧客の期待どおりに機能し、包括的で、対象のマーケットの目的にかなっていることを確認します。

プロダクト所有者と性能のベンチマークを決定します。パイプラインに性能テストを統合し、このベンチマークを使用してパイプラインの合格または失敗を判断します。性能テストを継続的なデリバリーのパイプラインに統合する必要はないと一般には信じられていますが、そうしなければ継続的パラダイムは破壊されます。

近年、大きな組織で情報漏えいが発生し、サイバーセキュリティの脅威がこれまでになく高まっています。製品は、記述したコードにも、またはコードにインポートしたサードパーティ ライブラリの中にも、セキュリティの脆弱性がないことを確認する必要があります。実際、主な情報漏えいは OSS (オープン ソース ソフトウェア) で発見されており、これらのエラーにフラグを立て、パイプラインによって強制的に中止するツールや技術を取り入れる必要があります。DAST (動的解析セキュリティ テスト) は、セキュリティの脆弱性を発見するための実証済みの方法です。

次の図は、コンポーネントフェーズとサブシステムフェーズで説明したワークフローをまとめたものです。独立したステップを並行して実行し、全体的なパイプラインの実行時間を最適化して、素早くフィードバックを得ることができます。

サブシステムが機能、パフォーマンス、セキュリティの期待を満たしたら、システム全体をリリースする場合に、疎結合サブシステムからシステムを組み立てるようにパイプラインに指示できます。つまり、最も速いチームは最も遅いチームの速度で進めるということです。これは「鎖の強さはその中の最も弱い環によって決まる」という古いことわざを想起させます。

この構成に対して、サブシステムがシステムに構成されて全体としてリリースされる、アンチパターンをお勧めします。このアンチパターンは、成功のためにすべてのサブシステムを密接に結び付けます。個別にデプロイ可能なアーティファクトに投資すれば、このアンチパターンを回避できます。

システム全体を検証する必要がある場合は、統合、パフォーマンス、セキュリティの各テストによって認定を受けられます。サブシステム フェーズとは異なり、このフェーズのテスト中にモックやスタブを使用しないでください。また、何よりもインターフェースとネットワークのテストに重点を置くことが重要です。

次の図は、構成を使用してサブシステムを組み立てるときのために、システムフェーズのワークフローをまとめたものです。サブシステムを本番環境に進めることができる場合でも、この図はコードをこのフェーズから次のフェーズに進める際に必要なソフトウェアのゲートを確立するのに役立ちます。

パイプラインは、変更リクエスト (CR) を自動的に提出して監査証跡を残せます。ほとんどの組織ではこのワークフローを標準変更、つまり計画されたリリースに使用します。このワークフローは、緊急変更や計画外リリースにも使用する必要がありますが、一部のチームは手を抜く傾向があります。変更リクエストは、エラーで強制的に中止された際は CD パイプラインによって自動的に閉じられることに注意してください。これによって変更リクエストが、パイプライン ワークフローの途中で放棄されないようにします。

次の図は、CD システムフェーズで説明したワークフローをまとめたものです。いくつかの手順では人間が介入する場合があり、これら手動の手順はパイプラインの手動ゲートの一部として実行することができます。そのままの状態でマッピングすると、可視化されたパイプラインは製品リリースのバリューストリームマップに極めて近づきます。

組み立てられたシステムが認証されたら、変更を加えずに本番環境に進めます。

サブシステムを独立してデプロイできるとしても、システムに組み込むとしても、このアーティファクトのバージョンはこの最終フェーズの一環として本番環境にデプロイされます。

ゼロ ダウンタイム デプロイ (ZDD) は、顧客のダウンタイムを防ぐためのものであり、テスト、ステージング、本番環境までの段階で実行する必要があります。Blue-green deployment (ブルー/グリーン デプロイ) は人気の ZDD 技術です。ここでは新しい部分をわずかなサンプル対象 (「グリーン」と呼ばれる) にデプロイしつつ、大部分は従来の「ブルー」のままにします。いざとなれば、全員を「ブルー」に戻し、顧客への影響があっても最小限に抑えます。「グリーン」で問題がない場合は、全員をゆっくり「ブルー」から「グリーン」に接続していきます。

しかし、一部の組織では手動ゲートが誤用されています。そのような組織では、チームが変更諮問委員会 (CAB) による会議で手動承認を得るように要求されます。その理由は多くの場合、職務分掌または関心の分離を誤って解釈しているためです。先に進めるための承認を得るためにある部門から別の部門にハンドオフします。また、本番環境に移行する変更について CAB 承認者の技術的理解が浅いために、手動承認のプロセスが恐ろしく時間がかかるものになっている例もありました。

これは、継続的なデリバリーと継続的デプロイの違いを明確にするのに良い話題の転換です。継続的なデリバリーでは手動ゲートを可能にできますが、継続的デプロイではできません。どちらも CD と呼ばれていますが、継続的デプロイではパイプラインに人間の介入がないため、より多くの規律と厳密さが必要です。

部分的に移動するのとそれらを作動させるのは異なります。本番環境では、統合、性能、セキュリティのテスト スイートのサブセットであるスモーク テストを実施します。スモーク テストに合格したら、それぞれの部分がオンになり、製品が稼働し、お客様が使用できるようになります。

次の図は、継続的なデリバリーのこの最終フェーズでチームが実行するステップを示しています。

継続的なデリバリーおよび継続的デプロイを成功させるには、継続的インテグレーションと継続的テストを適切に実行することが重要です。基盤を強固にすることで、品質、頻度、予測性の 3 つで勝利を収めることができます。

継続的なデリバリー パイプラインは、一連の持続可能な実験を通じてアイデアを製品にするのに役立ちます。アイデアが思ったほど良くないことがわかったら、さらに優れたアイデアですぐに方向転換できます。さらに、パイプラインは平均解決時間 (MTTR) の本番環境の課題を減らせるため、顧客のダウンタイムを削減します。継続的なデリバリーを使用すると、チームの生産性が高まって顧客が満足することになります。誰の反対を買えるというのでしょう?

詳細については、継続的なデリバリーのチュートリアルをご覧ください。