自動化されたビルド、テスト、デプロイが 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」とは、完成した (恐らく安全でない) 製品を評価に送るのではなく、設計フェーズから製品にセキュリティ対策を組み込むという考え方です。


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.