The epiphany of integration points is that they control product development. They are the leverage points to improve the system. When timing of integration points slip, the project is in trouble.

—Dantar Oosterwal, The Lean Machine

継続的な統合

継続的な統合（CI）は、新しい機能が開発、テスト、統合、そしてデプロイメントとリリースの準備のために検証される継続的デリバリーパイプラインの側面です。

CIは、継続的デリバリーパイプラインを構成する4つの側面の2つ目であり、それらは継続的な探索（CE）、継続的な統合（CI）、継続的なデプロイメント（CD）、そしてリリースオンデマンド（図1）です。

図1 継続的な統合は、継続的デリバリーパイプラインのコンテキストで行う

詳細

継続的な統合は、各アジャイルリリーストレイン（ART）にとって、品質を向上しながら、リスクを減らし、そして迅速で信頼性のある持続可能な開発のペースを確立する重要な技術的プラクティスです。

継続的な統合により、システムは常に稼働しており、開発中であってもデプロイ可能な状態になります。 CIは、小規模でテスト済みの縦のスレッドが独立してバリューを提供できるソフトウェアソリューションに、最も簡単に適用できます。しかし、大規模でマルチプラットフォームのソフトウェアシステムでは、CIの適用はより難しくなります。各プラットフォームには、新しい機能を検証するために継続的な統合が必要な技術的構成があります。ソフトウェア、ハードウェア、コンポーネント、およびサプライヤーが提供するサービスを含むシステムで構成されている場合、CIはさらに複雑になります。しかし、フィーチャーを頻繁に統合してテストすることが、ソリューションを完全に検証する唯一の実用的な方法であることに変わりません。　

その結果、チームは品質を構築し、統合された仕事に対して迅速なフィードバックを得ることができるバランスの取れたアプローチが必要となります。単なるソフトウェアベースのソリューションの場合、継続的な統合は最新のツールで比較的簡単に実現することができます。しかし、ハードウェアとソフトウェアを備えたより複雑なシステムには、頻度、統合のスコープ、およびテストとの間の経済的トレードオフをバランスさせるために継続的な統合アプローチが必要です。（エンタープライズソリューションデリバリーの記事を参照。）

継続的な統合の四つのアクティビティ

図2で示されているように、SAFeは継続的な統合に関連する4つのアクティビティを説明しています。

開発は、ストーリーを実装し、コードとコンポーネントをバージョン管理にコミットするために必要なプラクティスを説明します。
構築は、デプロイ可能なバイナリを作成し、開発ブランチをトランクにマージするために必要なテクニックを説明しています。
エンドツーエンドのテストは、ソリューションを検証するために必要なプラクティスを説明しています。
ステージは、本番前にステージング環境でソリューションをホストし、検証するためのステップを説明しています。

図2 継続的な統合の4つのアクティビティ

開発

ソリューションの開発とは、必要に応じてARTバックログからフィーチャーを洗練し、ストーリーを実装し、コーディング、テスト、作業成果物をソース管理システムにコミットを行うことです。このアクティビティでのテストは、ユニットテストやストーリーレベルのテストに焦点を当て、他の利用可能でない、または簡単にテストできないコンポーネントやサブシステムを再現するために、テストダブル（テスト駆動開発参照）がしばしば必要となります。

ソリューションを開発するためには、いくつかのプラクティスが関連しています。

フィーチャーをストーリーに分割する - これにより、小さなバッチによる継続的デリバリーとスムーズな統合が可能になります。また、ワークフローが顧客のニーズを満たすことを確認するためのユーザーストーリーマップの作成なども含まれます。
ビヘイビア駆動開発 (BDD) - BDDは、プロダクトオーナーとチームが要件をより理解し、受け入れ基準を作成し、テストを自動化することで品質を向上させるプロセスで、コードが書かれる前に行われます。 BDDはTDDと連動し、ここで説明されています。
テスト駆動開発 (TDD) - TDDは、まずユニットテストを書き、そのテストに合格するために必要最小限のコードを構築することを含みます。このテストテクニックは、より良いデザイン、高い品質、そして増加した生産性にリードします。 TDDはBDDと連動し、さらに詳しくはこちらで説明されています。
バージョン管理 - 効果的なバージョン管理により、チームは問題から迅速に回復し、品質を向上させ、適切なコンポーネントの統合を確保します。バージョン管理の下で資産を集約することは、継続的な統合の成熟度の先行指標です。
作り込み品質 - 作り込み品質は、フロー、アーキテクチャとデザインの品質、コードの品質、システム品質、およびリリース品質に関するプラクティスを規定します。
アプリケーションの遠隔測定 - アプリケーションの遠隔測定は、関連する仮説の結果を決定するのに役立つアプリケーションデータを取得し、使用する主要なメカニズムです。
脅威モデリング - 継続的な探索（アーキテクトステップ）で行われる脅威モデリングに加えて、システム設計は、チームが新しい機能を導入することで生じる可能性のある脆弱性を特定する必要があります。

構築

構築フェーズでは、チームは継続的に新しいコードを統合します。コードのコミット時に実行される構築とテストのツールを自動化は、統合するための最良の方法の一つです。合格と未合格、および問題ありの自動テストは、進捗状況の客観的な指標です。コードの自動構築を可能にすることで、システムのより重要な部分に影響を及ぼす前に、チームは問題を迅速に修正し、壊れたビルドを対処することを最優先されるべきです。「ゲーテッドコミット」は、ソフトウェアがゲート（例えば、ユニットテスト、パフォーマンステスト、既知の欠陥が無いなど）を通過したことを確認するためのもので、メインのコードベースまたはトランクにチェックインされる前に行われます。テストに合格したコードは自動的に統合され、複数のソースコードブランチを管理する複雑さが解消されます。トランクベースの開発は、高コストのコードフリーズなしでコードをオンデマンドでリリースできるようにするのに役立ちます。

以下は高品質なソリューションを構築するための5つのプラクティスです。

継続的なコード統合 - コードのコミットは、変更のコンパイルとテストを自動的にトリガーするべきです。理想的には、これはコミットごとに、一日に数回起こるべきです。
構築とテストの自動化 - 自動化されたコンパイルプロセスには、変更を確認するためのユニットテストとストーリーレベルのテストが含まれ、多くの場合、迅速な構築を可能にするために、他のシステムを複製し、テストダブルが必要となります。
トランクベースの開発 - チームはコードを、少なくとも1日に1回、理想的にはコミット時に統合するべきです。そしてすべてのチームは単一のトランクから作業を行うべきで、長時間存在するブランチを避けるべきです。
ゲーテッドコミット - メインのトランクにコミットすることは、壊れた変更が多くのチームに影響を及ぼす可能性が高くなるというリスクが伴います。したがって、構築およびテストプロセスを通じて検証された変更のみがこのブランチにマージされます。
アプリケーションセキュリティ - コード分析ツールは、コードとサードパーティのパッケージを既知の脆弱性について調査します。

ソリューションをエンドツーエンドでテストする

重要ではありますが、自動化されたローカルのストーリーとコンポーネントのテストだけでは十分ではありません。フィーチャーを徹底的にテストするためには、システムレベルの統合とテストが必要です。図3は、システムチームがARTのすべてのチームの仕事を頻繁に統合するのをどのように支援し、進捗状況の一部のオブジェクティブな証拠を提供するかを示しています。

図3 全てのチームの仕事をARTに統合する

システムレベルのテストは、毎回のコミット後、そして頻繁にイテレーション中に行うことが理想的です。しかし、どのような状況であれ、全システム統合は1イテレーションで少なくとも１回は達成しなければなりません。そうでなければ、過去のイテレーションからの欠陥や問題の発見が遅れ、大幅な再作業と遅延を引き起こします。

エンドツーエンドシステムテストを改善するための6つのプラクティス：

テストと本番環境の一致 - 環境の一致は、テストがライブユーザーの前でソリューションがどのように動作するかを確認することにより、欠陥が本番環境に流出する確率を減らします。
テスト自動化 - 自動テストは、機能、統合、リグレッションなど、さまざまなテストを含むべきです。アジャイルテストの記事では、何を、そして何を自動化すべきかのテストマトリックスの詳細を説明しています。
テストデータマネジメント - 安定性を確保するために、テストは一貫性があり、現実的でなければならず、可能な限り本番を再現し、ソースコントロールの下で行われるべきです。
サービスの仮想化 - 異なる種類のテストには異なる環境が必要です。サービスの仮想化により、チームは物理的なインフラストラクチャの作成と管理に関連するコストと労力をかけずに、本番環境をシミュレートすることができます。
非機能要件 (NFR) のテスト - セキュリティ、信頼性、パフォーマンス、拡張性、ユーザビリティなどのシステム属性は重要であり、テストが必要です。
サプライヤーとの継続的な統合 - サプライヤーは、リードタイムを短縮し、バリューのデリバリーを改善するためのユニークな貢献をもたらすため、継続的な統合が必要です。その為に、共有の統合ケイデンスを採用し、客観的な評価のマイルストーンを確立すると効果的です。

ステージ

最後に、ARTは以下の実践に基づいてステージングで全体のソリューションを検証する必要があります。

ステージング環境を維持する -本番に非常に近いステージング環境は、そのような検証の場を提供します。
ブルー/グリーンデプロイメント - ブルー/グリーンデプロイメントパターンには、本番とステージングの２つの環境を含みます。デプロイメントの準備の為に、アイドル、ステージ、そして本番へと変更は連続的に、そして継続的にフローされます。変更の準備ができたら、コンフィグレーションで2つの環境を切り替えます。アイドルは本番になり、古い本番環境は新しいアイドルになります。このアプローチにより、継続的デリバリー、ダウンタイム無しのデプロイメント、そして迅速な障害復旧が可能になります。
システムデモ - これは、ステークホルダーがソリューションが本番デプロイメントに向けた準備ができているかを評価する場です。

継続的な統合の文化を促進する

大規模で複雑なシステムを継続的に統合することは、時間がかかります。次のセクションでは、成功するCI文化と実践を構築するためのいくつかの提案を紹介しています。

頻繁に統合する - チームが頻繁に統合するほど、問題を早く見つけることができます。それが行うのがより困難であるほど、彼らがそれを行う必要がより頻繁になります。この実践は阻害要因を排除し、途中で自動化を追加することで、学習サイクルが速くなり、再作業が減少します。
統合結果を可視化する - 統合プロセスが失敗したとき、誰もがその原因を知るべきです。それが修正されたら、新しいテストを作成することで、より早く問題を検出し、再発を防ぐことが出来る筈です。
不合格の統合を修正することは最優先事項です - 統合の不合格があっても作業を続けるチームは、本番用システムを構築する際に必要なバリューと文化を理解していません。チームは、壊れたビルドに注意を促し、システムが故障したままの時間の割合を表示する点滅するランプや通知を活用し、目に見える指標を確立します。
共有ケイデンスを確立する - 統合ポイントは、すべてのチームが同じ一貫したリズムに従うときにより明確になります。仮にチームがイテレーション内で完全な統合を行うことができないとします。その場合、何が可能かを洗い出し、短期的なトレードオフを行いながら、完全な統合という目標に向けてテクニックとインフラストラクチャを継続的に改善することができます。
適切なインフラストラクチャを開発し、維持する - 効果的で継続的な統合は、テストとステージング環境の可用性に左右されます。インフラストラクチャは、言うまでもなく投資です。しかし、リーンアジャイルリーダーは長期的な視点を持ち、これからのマラソンのためのベロシティを上げるために今日必要な投資を行います。
支援的なソフトウェアエンジニアリングの実践を適用する - 継続的な統合は、それらの問題を念頭に置いてシステムを設計すれば、より利用しやすくなります。テストファーストの開発とテスト可能性のためのプランニングは、よりモジュラー化されたソリューションと関心の分離、主要なインターフェー継続的な統合継続的な統合インターフェースと物理的なテストポイントの使用が求められます。

CI文化の別の重要な側面は、パイプラインを通じてのバリューフローを迅速に確保することです。 ARTフローの記事を詳しくご覧いただくと、途切れることのないバリューフローを実現する（原則＃6）についての詳細がわかります。

DevOpsを用いて継続的な統合を可能にする

継続的な統合は、もともとDevOpsの「Dev」を触発した重要な「開発」アクティビティを含んでいます。これらのアクティビティは、ソリューションの開発と、プレ本番環境を通じたパイプラインフローに焦点を当てています。 DevOpsの考え方、実践、およびツールをこのバリューストリームのセグメントに適用することで、迅速な開発、頻繁なコードの統合、作り込み品質とコンプライアンスが可能になります。

図4に示すように、SAFeのCALMRアプローチはDevOps（中央）を可能にし、継続的な統合といくつかの実践分野（内側のリング）を可能にします。 4つのアクティビティ（緑色）のそれぞれは、ビジネスバリューのデリバリーと品質を最大化し、学習を検証するために、複数の分野からのDevOpsの専門知識を活用する共同作業です。

図4 DevOpsは継続的な統合を可能にする

例えば、継続的デリバリーパイプラインでソリューションを構築することは、複数のDevOps分野をまたぎます。バージョン管理にコードをチェックインすると、デプロイメントパイプラインがトリガーされ、自動的にマージ、品質、セキュリティの確認が行われ、次にコードとして保存されたコンフィグレーションが適用されて、出荷可能なフルスタックのバイナリを構築します。 DevOpsを使用すると、このプロセスは通常、ソースコードを迅速にテスト済みのデプロイ可能なソリューションに変換します。

すべての4つの継続的な統合アクティビティはDevOpsによって可能になりますが、技術的な実践とツールの組み合わせは異なります。 DevOpsと継続的デリバリーパイプラインがどのように可能になるかについての詳細なガイダンスについては、DevOpsの記事シリーズをご覧ください。

詳しく学ぶ

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. AMACOM, 2010.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series). Pearson Education, 2007.

[3] Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

最終更新： 2023年1月6日