多段階継続的インテグレーション

多段階継続的インテグレーションは、統合問題の範囲を縮小しながら、高度に統合された並行開発活動を実現することを目的としたソフトウェア開発手法である。 ^[1]

マルチステージ継続的インテグレーションは、ソフトウェア開発の基本的な統合パターンを活用します。ソフトウェアは、未成熟な状態から成熟した状態へと段階的に移行し、作業は論理ユニットに分割され、相互依存するチームが時間の経過とともにさまざまな部分を統合します。ショップごとに異なるのは、ステージの数、チームの数と規模、およびチームの相互依存関係の構造です。

マルチステージ継続的インテグレーションは継続的インテグレーションの拡張であり、すでに推奨プラクティスに従っていることを前提としています。

プロジェクトが大きく複雑になるほど、プロジェクトが不安定になる可能性が高くなります。プロジェクトが大きくなるにつれて、アラートや壊れたビルドが増加します。進捗は遅くなり、メインラインはますます不安定になります。開発者の数と場所が増えるにつれて、ビルドの失敗のリスクは指数関数的に増加します。^[2]

各開発者は自分のタスクに取り組みます。変更を加えると、そのチームのブランチに対して継続的インテグレーションが行われます。成功しない場合は、その開発者が (おそらくチームメイトの助けを借りて) ブランチを修正します。問題が発生した場合、影響を受けるのは開発作業全体ではなく、そのチームだけです。これは、現代のリーン製造施設でラインを停止する方法に似ています。ライン上の誰かが「ライン停止」コードを引いた場合、それはライン全体ではなく、ラインの一部分のみに影響します。

近年、「トピック」または「機能」ブランチモデルがチームベースのブランチモデルよりも人気が高まっていることは注目に値します。たとえば、人気のGit-Flowブランチモデル^{[3]を参照してください。}

チームは頻繁に、第 2 フェーズであるメインラインとの統合に進むことを決定します。このフェーズでは、チームはメインライン開発の場合に個人が行うのと同じことを行います。チームのブランチには、メインラインからのすべての変更がマージされている必要があり (ワークスペースの更新に相当)、ビルドが成功し、すべてのテストに合格する必要があります。メインラインとの統合は、進行中の機能ではなく、事前に統合された機能のみが含まれるため、通常よりも簡単です。次に、チームの変更がメインラインにマージされ、メインラインでビルドとテストのサイクルが開始されます。これに合格すると、チームは最初のフェーズに戻り、個々の開発者が自分のタスクに取り組みます。それ以外の場合は、チームは、個人がメインラインで作業しているかのように、メインラインを再び機能させることに取り組みます。

変更は可能な限り迅速に伝播し、問題が発生した場合のみ停止します。理想的には、変更はメインライン開発と同じ頻度でメイン統合領域に伝わります。違いは、メイン統合領域に伝わる問題が少ないことです。多段階の継続的インテグレーションにより、高度な統合を並行して実行しながら、統合の問題の範囲を大幅に削減できます。^[4]

多段階の継続的インテグレーションでは、各チームが独自のブランチを持つ必要があります。

多段階継続的インテグレーションには多くの利点がある: ^{[引用が必要]}

• ユニットテストが失敗したり、バグが発見されたりすると、開発者はデバッグに時間を費やすことなく、コードベースをバグのない状態に戻すことができます。
• 統合の問題は継続的に検出され、修正されます。リリース日直前の中断はありません。
• 壊れた/互換性のないコードの早期警告。
• 矛盾する変更の早期警告。
• すべての変更を即時に単体テストします。
• テスト、デモ、リリースの目的で「現在の」ビルドを常に利用できること。
• 不完全なコードや壊れたコードをチェックインすることによる即時の影響は、開発者がより短いフィードバック サイクルで段階的に作業することを学ぶ動機として機能します。

多段階の継続的インテグレーションをサポートするツールには次のものがあります。

• AccuRev ^[5] - バージョン管理とALMツール
• Electric Cloud ^[5] — ソフトウェア生産ライフサイクルを自動化するために設計されたビルド、テスト、展開フレームワークツール
• AnthillPro - ビルド、依存関係、リリースツール^[6]
• ラショナル・チーム・コンサート^[7] ALMプラットフォーム

• アジャイルソフトウェア開発
• ビルドの自動化
• 継続的なデザイン
• 継続的インテグレーション
• テスト駆動開発
• アプリケーションライフサイクル管理