Close

継続的デリバリー

継続的なデリバリー (CD) は、ソフトウェアのリリースを自動化し、短いイテレーションで実行する方法です。

継続的なデリバリーとは?


継続的なデリバリーとは、チームが高品質の製品をソース コード リポジトリから本番環境に、頻繁かつ予測可能な方法で自動でリリースするアプローチです。

一部の組織では、製品を 1 つのチームから次のチームに引き渡すことで手動でリリースしています。以下の図をご参照ください。通常、開発者がこの図の左端、運用担当者が受取側にいます。ハンドオフのたびに遅延が生じるので、チームは苛立って顧客は不満を覚えます。面倒でエラーが生じやすいプロセスの末にようやく製品が稼働しますが、収益の創出は遅れます。

図 1: 手動による顧客への製品リリース
手動リリースのステップ: 開発、QA、ツール、インフラストラクチャ、プラットフォーム、リリース、情報セキュリティ

それでは、以下の継続的なデリバリー パイプラインをご確認ください。この図は、開発者が各自のラップトップでコードを記述して、その変更を Bitbucket などのソース コード リポジトリにコミットする方法を示しています。コードとは、テスト対象のシステム、テスト、およびシステムのデプロイと保守に使用されるインフラストラクチャを意味します。Bitbucket Pipelines は、製品をテストからステージング、本番環境へとリリースして、これらの優れた新機能がお客様の手に渡るようにサポートします。

図 2: 自動でリリースする継続的デリバリーのパイプライン
継続的なデリバリーのパイプライン ステップ: 開発者、ラップトップ、Bitbucket、Bitbucket Pipelines、顧客

継続的なデリバリーはどのように機能するか?


継続的なデリバリー パイプラインでは、本番環境の直前に手動ゲートを設置できます。手動ゲートには人間の介入が必要で、組織にはパイプラインに手動ゲートが必要なシナリオが存在する可能性があります。手動ゲートの中には不適正なものもあれば、適正なものもあります。適正なシナリオの 1 つとして、ビジネス チームが最後の段階でリリースの決定を下すというものがあります。各スプリントの後、エンジニアリング チームがリリース可能なバージョンの製品を準備して、ビジネス チームがすべての顧客または特定の顧客 (たとえば、特定の地理的場所に住む顧客) に製品をリリースする最終的な指示を出します。

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

また、製品のアーキテクチャはパイプラインのさまざまなフェーズに影響を与えて、各フェーズで生成されるアーティファクトにも影響します。パイプラインでは、最初にコンポーネントが構築されます。これは、製品の配布可能かつテスト可能な最小のユニットです。たとえば、パイプラインによって構築されたライブラリはコンポーネントと呼べます。これが、コンポーネント フェーズです。

疎結合のコンポーネントによって構築されるサブシステムは、デプロイおよび実行可能な最小単位です。たとえば、サーバーはサブシステムです。コンテナーで実行されるマイクロサービスもサブシステムの一例です。これが、サブシステム フェーズです。コンポーネントとは異なり、サブシステムは立ち上げ検証できます。

したがって、システム全体をリリースする必要がある場合は、パイプラインに指示して疎結合のサブシステムからシステムを組み立てられます。これが、システム フェーズです。

サブシステムを結合してシステムを組み立てるこの構成はお勧めしません。この仕組みを図 3 に示します。

図 3: サブシステムを結合してシステムを構築
サブシステムのダイアグラム

このすべてか無かのアプローチでは、最も遅いサブシステムが最も速いサブシステムのボトルネックとなります。私たちは「鎖の強さは最も弱いつなぎ目で決まる」という決まり文句によって、このアーキテクチャ パターンに陥るチームに警告しています。

検証が完了すると、組み立てられたシステムは、本番フェーズと呼ばれる最終フェーズでそれ以上変更を加えることなく本番環境に実装されます。

これらのフェーズは物理的というよりも論理的な性格が強く、大きな問題を複数の小さな問題に分割するためだけに作成される点にご注意ください。フェーズの数は、アーキテクチャと要件によって異なります。

いくらスピードが速くても品質が伴わなければ、お客様にとって役に立ちません。継続的なテストとは、自動テストをソフトウェア デリバリー パイプラインに統合して、そこに流れるすべての変更を検証する手法です。パイプラインの各フェーズでテストが実行されて、そのフェーズで生成されたアーティファクトが検証されます。単体テストと静的コード分析によって、パイプラインのコンポーネント フェーズのコンポーネントが検証されます。機能、パフォーマンス、セキュリティの各テストによってサブシステム フェーズのサブシステムが、統合、パフォーマンス、セキュリティの各テストによってシステム フェーズのシステムが、最後に、スモーク テストによって本番フェーズの製品が検証されます。

コードレビューのイラスト

自動テストをパイプラインに統合

モノリシックな製品アーキテクチャ、つまり Big Ball of Mud (大きな泥だんご) は、Big Ball of Tests (テストの大きな泥だんご) になる可能性があります。独立してデプロイ可能なアーティファクトが高度に統合された環境で認証を受ける必要なくパイプラインを通過できるように、マイクロサービスへの投資をお勧めします。また、独立してデプロイ可能なアーティファクトによって、遅いチームが速いチームのボトルネックになることを防げます。

継続的なデリバリーの価値


ソフトウェア デリバリー パイプラインはそれ自体が製作物であり、ビジネスにとっての優先事項です。そうでなければ、収益を生み出す製品をパイプラインを通じて送るべきではありません。継続的なデリバリーは 3 つの方法で価値を付加します。それは、ソフトウェア開発チームのベロシティ、生産性、持続可能性の向上です。

ロケットのイラスト

ベロシティ

ベロシティとは責任のあるスピードであって、自暴自棄なそれではありません。パイプラインの目的は、質の高い製品をお客様にお届けすることです。チームの意識が低ければ、ただ速いだけで問題の多いコードを本番環境に連発してしまう可能性があります。自動化されたソフトウェア デリバリー パイプラインによって、組織が市場の変化に的確に対応できるようになります。

コード パイプラインのイラスト

生産性

本番環境に移す、すべての変更について変更リクエストを提出するといった退屈なタスクを人間の代わりにパイプラインで実行することによって、生産性が向上します。これによって、スクラム チームはロジスティクスに労力をかけずに、世界を驚かせる製品に集中できます。ひいては、チーム メンバーの満足度が高まって仕事への積極性が増し、チームに長く留まりたいという気持ちが強まります。

意思決定のイラスト

持続可能性

持続可能性は、IT に留まらないあらゆる企業にとって重要です。「ソフトウェアは世界を飲み込もうとしている」はもはや真実ではなく、ソフトウェアはすでに世界を飲み込んでいます。医療、金融、小売、または分野を問わずその他すべての企業がテクノロジーを駆使して差別化を図り、競合他社より優位に立とうとしています。自動化によって、エラーが起こりやすく繰り返しの多い手動タスクを削減/排除できるため、より適切かつ迅速にイノベーションを起こしてお客様のニーズを満たせます。

誰がいつ継続的なデリバリーを行うか?


継続的なデリバリーを採用する最適なタイミングはいつですか? もうとっくに過ぎています。
チームは次のような優先順位付けされた単一のバックログを必要としています。

  1. 継続的なデリバリーが後回しにされないで採用されている
  2. ユーザー ストーリーの承認基準に、手動ではなく自動のソフトウェア デリバリー アプローチが明記されている
  3. スプリントの DoD (「完了」の定義) によって、チームは製品が手動でリリースされたスプリントを終了できない

継続的なデリバリーは取り入れるべき正しい手法です。ときには、推進派が活を入れて変革を起こす必要があります。正しく設計されていれば、継続的なデリバリー パイプラインは最終的には採算が取れるものです。

それでは、誰に任せればよいでしょうか?

一部の組織では、経験の浅い人物に継続的なデリバリー パイプラインの設計と実装を任せてしまい、その複雑さを身をもって学びました。経験の浅いメンバーを任命すると、継続的なデリバリーは優先度が低いかのような印象を与える誤ったシグナルをチームに送りかねません。テクノロジーとビジネスに造詣が深いシニア アーキテクトを任命することを強くお勧めします。

継続的なデリバリーを超えて


継続的なインテグレーションテストデリバリーデプロイ、分析のどの段階にいるかに関わらず、その中心にあるのはチェックリストでも宛先でもなく、継続的な改善です。

遅かれ早かれ、継続的なデリバリーのパイプラインが構築されるときは、組織の全員が参加することになります。エグゼクティブ、エンジニアリング、製品管理、ガバナンス、リスク、コンプライアンス、情報セキュリティ、オペレーション、法務、その他あらゆる部門で、パイプラインがサイロや壁を打ち崩すでしょう。全員が何らかのかたちでこの変革の一端を担い、継続的組織が新しい標準となるのです。

CI/CD を開始する

CI/CD を実践するために、開発、デプロイとテストを自動化するツールを使用できます。あるツールは統合に、他のツールは開発とデプロイに、他のツールはテストに使用できます。

アトラシアンでは、CI/CD など、エンドツーエンドの DevOps プロセスを実現する、Open DevOps ソリューションを提供しています。チームは Bitbucket に組み込まれた統合型 CI/CD サービスである Bitbucket Pipelines を含むさまざまな CI/CD ツールを使用できます。リポジトリの構成ファイルに基づいてコードを自動的にビルド、テスト、デプロイできます。Open DevOps はまた、Harness、GitLab、JFrog、Codefresh、CircleCI など、他の CI/CD ツールとも統合されます。

ここでは、当社の Open DevOps 統合を詳しく見ていきます。当社の DevOps CI/CD のチュートリアルを是非ご確認ください。

すばやく価値を提供のイラスト