閉じる

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

自動化されたビルド、テスト、デプロイが 1 つのリリースワークフローでどのように連鎖するかを説明します。

継続的デリバリーパイプラインとは何ですか?

How does a pipeline relate to continuous delivery (CD)? As the name suggests, a continuous delivery pipeline is an implementation of the continuous paradigm, where automated builds, tests and deployments are orchestrated as one release workflow. Put more plainly, a CD pipeline is a set of steps your code changes will go through to make their way to production.

A CD pipeline delivers, as per business needs, quality products frequently and predictably from test to staging to production in an automated fashion.

For starters, let’s focus on the three concepts: quality, frequently, and predictably.

We emphasize on quality to underscore that it’s not traded off for speed. Business doesn’t want us to build a pipeline that can shoot faulty code to production at high speed. We will go through the principles of “Shift Left” and “DevSecOps”, and discuss how we can move quality and security upstream in the SDLC (software development life cycle). This will put to rest any concerns regarding continuous delivery pipelines posing risk to businesses.

Frequently indicates that pipelines execute at any time to release features, since they are programmed to trigger with commits to the codebase. Once the pipeline MVP (minimum viable product) is in place, it can execute as many times as it needs to with periodic maintenance cost. This automated approach scales without burning out the team. This also allows teams to make small incremental improvements to their products without the fear of a major catastrophe in production.

Cliche as it may sound, the nation of “to err is human” still holds true. Teams brace for impact during manual releases since those processes are brittle. Predictably implies that releases are deterministic in nature when done via continuous delivery pipelines. Since pipelines are programmable infrastructure, teams can expect the desired behavior every time. Accidents can happen, of course, since no software is bug-free. However, pipelines are exponentially better than manual error-prone release processes, since unlike humans, pipelines don’t falter under aggressive deadlines.  

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

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

Continuous delivery pipeline articles

[続き]

継続的デリバリーパイプラインのフェーズ

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

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

Even if you foresee more than four phases or less than four in your organization, the concepts outlined below still apply.

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

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

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

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

CD Component phase

The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. A component can be certified, among other things, by code reviews, unit tests, and static code analyzers.

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

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

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

Static code analysis detects problems in code without executing it. This is an inexpensive way to detect issues. Like unit tests, these tests run on source code and have low run-time. Static analyzers detect potential memory leaks, along with code quality indicators like cyclomatic complexity and code duplication. During this phase, SAST (static analysis security testing) is a proven way to discover security vulnerabilities.

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

CD サブシステムフェーズ

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

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

Subsystems can be deployed and certified by functional, performance, and security tests. Let’s study how each of these test types validate the product.

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

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

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

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

A) Certifying components and/or subsystems in the test environment

CD システムフェーズ

Once subsystems meet functional, performance, and security expectations, the pipeline could be taught to assemble a system from loosely coupled subsystems in cases where the entire system has to be released as a whole. What that means is that the fastest team can go at the speed of the slowest team. Reminds me of the old saying, “A chain is only as strong as its weakest link”.

We recommend against this composition anti-pattern where subsystems are composed into a system to be released as a whole. This anti-pattern ties all the subsystems at their hips for success. If you invest in independently deployable artifacts, you will be able to avoid this anti-pattern.

Where systems need to be validated as a whole, they can be certified by integration, performance, and security tests. Unlike subsystem phase, do not use mocks or stubs during testing in this phase. Also, focus on testing interfaces and network more than anything else.

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

The pipeline can automatically file change requests (CR) to leave an audit trail. Most organizations use this workflow for standard changes, which means, planned releases. This workflow should also be used for emergency changes, or unplanned releases, although some teams tend to cut corners. Note how the change request (CR) is closed automatically by the CD pipeline when errors force it to abort. This prevents CRs from being abandoned in the middle of the pipeline workflow.

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

B) ステージング環境でサブシステムやシステムを認証する

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

CD 本番フェーズ

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

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

一部の組織では パイプラインを本番環境にデプロイする前に、手動ゲートが必要になります。世界にリリースする前に特定の地域または層の人口をターゲットとしてデータを収集したい場合など、手動ゲートが適正なケースもあります。

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

This is a good segway to call out the difference between continuous delivery and continuous deployment. Continuous delivery allows manual gates whereas continuous deployment doesn’t. While both are referred to as CD, continuous deployment requires more discipline and rigor since there is no human intervention in the pipeline.

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

The following diagram illustrates the steps carried out by the team in this final phase of continuous delivery.

C) Certifying subsystems and/or system in the production environment

継続的デリバリーは新しい常識です。

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

A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the MTTR (mean time to resolve) production issues, thus reducing downtime for your customers. With continuous delivery, you end up with productive teams and satisfied customers, and who doesn’t want that?

Learn more in our Continuous Delivery tutorial.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.