継続的インテグレーション

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアエンジニアリングでは継続的インテグレーションCI )は、すべての開発者の作業コピーを1日に数回共有メインラインにマージする方法です。[1] Grady Boochは、1991年の方法CIという用語を最初に提案しましたが[2]、1日に数回統合することを提唱していませんでした。エクストリームプログラミング(XP)は、CIの概念を採用し、1日に2回以上、おそらく1日に数十回の統合を提唱しました。[3]

理論的根拠

変更に着手するとき、開発者は作業する現在のコードベースのコピーを取ります他の開発者が変更されたコードをソースコードリポジトリに送信すると、このコピーは徐々にリポジトリコードを反映しなくなります。既存のコードベースを変更できるだけでなく、新しいコードを追加したり、新しいライブラリや、依存関係や潜在的な競合を引き起こすその他のリソースを追加したりすることもできます。

メインラインにマージせずにブランチで開発を継続する時間が長いほど、複数の統合の競合[4]や、開発者ブランチが最終的にマージされたときに失敗するリスクが高くなります。開発者がリポジトリにコードを送信するときは、コピーを取得してからの変更をリポジトリに反映するように、最初にコードを更新する必要があります。リポジトリに含まれる変更が多いほど、開発者は独自の変更を送信する前に行う必要のある作業が多くなります。

最終的に、リポジトリは開発者のベースラインとは大きく異なり、「マージ地獄」または「統合地獄」と呼ばれることもある[5]に入り、統合にかかる時間が作成にかかる時間を超える可能性があります。元の変更。[6]

ワークフロー

ローカルでテストを実行する

CIは、テスト駆動開発の実践を通じて作成された自動化された単体テストと組み合わせて使用​​することを目的としていますこれは、メインラインにコミットする前に、開発者のローカル環境ですべての単体テストを実行して合格することによって行われます。これにより、ある開発者の進行中の作業が別の開発者のコ​​ピーを壊すのを防ぐことができます。必要に応じて、たとえばフィーチャートグルを使用して、コミットする前に部分的に完全な機能を無効にすることができます。

CIでコードをコンパイルする

ビルドサーバーは、定期的に、またはコミットのたびにコードをコンパイルし、結果を開発者に報告します。ビルドサーバーの使用はXP(エクストリームプログラミング)コミュニティの外部に導入されており、多くの組織はすべてのXPを採用せずにCIを採用しています。

CIでテストを実行する

自動化された単体テストに加えて、CIを使用する組織は通常、ビルドサーバーを使用して、一般的に品質管理を適用する継続的プロセスを実装しますユニットテストと統合テストの実行に加えて、このようなプロセスは、追加の静的分析を実行し、パフォーマンスを測定およびプロファイルし、ソースコードからドキュメントを抽出してフォーマットし、手動のQAプロセスを容易にします。オープンソース向けの人気のあるTravisCIサービスでは、CIジョブの58.64%のみがテストを実行します。[7]

この品質管理の継続的な適用は、すべての開発が完了した後に品質管理を適用する従来の慣行を置き換えることにより、ソフトウェアの品質を向上させ、ソフトウェアの配信にかかる時間を短縮することを目的としています。これは、統合を容易にするためにより頻繁に統合するという当初の考え方と非常によく似ており、QAプロセスにのみ適用されます。

CIからアーティファクトをデプロイする

現在、CIは、 CI / CDパイプラインと呼ばれるもので継続的デリバリーまたは継続的デプロイと絡み合っていることがよくあります。「継続的デリバリー」により、メインラインにチェックインされたソフトウェアが常にユーザーに展開できる状態になり、「継続的展開」により、展開プロセスが完全に自動化されます。

歴史

継続的インテグレーションに関する最も初期の既知の作業は、GE Kaiser、DE Perry、およびWMSchellによって開発されたInfuse環境でした。[8]

1994年、Grady Boochは、オブジェクト指向の分析とアプリケーションを使用した設計(第2版)[9]で継続的インテグレーションというフレーズを使用して、マイクロプロセスを使用して開発する場合、「内部リリースはシステムの一種の継続的インテグレーションを表し、マイクロプロセスの閉鎖を強制するために存在します。」

1997年、ケントベックロンジェフリーズは、継続的インテグレーションを含むクライスラー総合報酬システムプロジェクトでエクストリームプログラミング(XP)を発明しました。[1] [自費出版の情報源]ベックは1998年に継続的インテグレーションについて発表し、技術サポートよりも対面のコミュニケーションの重要性を強調しました。[10] 1999年、ベックはエクストリームプログラミングに関する彼の最初の完全な本でさらに詳しく述べました。[11]最初のオープンソースCIツールの1つであるCruiseControl [12] [自費出版ソース]は2001年にリリースされました。

2010年、Timothy Fitzは、 IMVUのエンジニアリングチームが最初の実用的なCIシステムを構築して使用した方法を詳しく説明した記事を公開しました。彼の投稿は元々懐疑的でしたが、すぐに理解され、これもIMVUに基づく リーンソフトウェア開発方法論の一部として広く採用されました[13] 。

一般的な慣行

このセクションでは、継続的インテグレーションを実現する方法と、このプラクティスを自動化する方法について、さまざまな作成者によって提案されたベストプラクティスを示します。ビルドの自動化は、それ自体がベストプラクティスです。[14] [15]

継続的インテグレーション(新しいコードまたは変更されたコードを既存のコードリポジトリと頻繁に統合する方法)は、コミットビルドの間にウィンドウが残らないように、また開発者がそれらに気づいてすぐに修正しなければエラーが発生しないように、十分に頻繁に発生する必要があります。[1]通常は、定期的にスケジュールされたビルドではなく、リポジトリへのコミットごとにこれらのビルドをトリガーします。迅速なコミットのマルチ開発者環境でこれを行うことの実用性は、通常、各コミットの後に短時間トリガーし、このタイマーの期限が切れたとき、または最後のビルドからかなり長い間隔の後にビルドを開始することです。 。新しいコミットごとに短時間トリガーに使用されるタイマーがリセットされるため、これは多くのボタンデバウンスアルゴリズムで使用される手法と同じであることに注意してください。[16]このように、コミットイベントは「デバウンス」され、一連のラピッドファイアコミット間の不要なビルドを防ぎます。多くの自動化ツールは、このスケジューリングを自動的に提供します。

もう1つの要因は、アトミックコミットをサポートするバージョン管理システムの必要性です。つまり、開発者のすべての変更は、単一のコミット操作と見なされる場合があります。変更されたファイルの半分だけからビルドしようとしても意味がありません。

これらの目的を達成するために、継続的インテグレーションは次の原則に依存しています。

コードリポジトリを維持する

このプラクティスでは、プロジェクトのソースコードにリビジョン管理システムを使用することを推奨しています。プロジェクトのビルドに必要なすべてのアーティファクトは、リポジトリに配置する必要があります。このプラクティスとリビジョン管理コミュニティでは、システムは新しいチェックアウトから構築可能であり、追加の依存関係を必要としないという慣習があります。エクストリームプログラミングの提唱者であるMartinFowlerは、分岐がツールによってサポートされている場合、その使用を最小限に抑える必要があるとも述べています。[17]代わりに、ソフトウェアの複数のバージョンを同時に維持するよりも、変更を統合する方が望ましいです。メインライン(またはトランク)は、ソフトウェアの動作バージョンの場所である必要があります。

ビルドを自動化する

1つのコマンドで、システムを構築する機能が必要です。makeなどの多くのビルドツールは何年も前から存在しています。その他の最近のツールは、継続的インテグレーション環境で頻繁に使用されます。ビルドの自動化には、統合の自動化を含める必要があります。これには、多くの場合、本番環境のような環境へのデプロイが含まれます。多くの場合、ビルドスクリプトはバイナリをコンパイルするだけでなく、ドキュメント、Webサイトのページ、統計、および配布メディア(Debian DEB、Red Hat RPM、Windows MSIファイルなど)も生成します。

ビルドをセルフテストにする

コードがビルドされたら、すべてのテストを実行して、開発者が期待どおりに動作することを確認する必要があります。[18]

誰もが毎日ベースラインにコミットします

定期的にコミットすることにより、すべてのコミッターは競合する変更の数を減らすことができます。1週間分の作業をチェックインすると、他の機能と競合するリスクがあり、解決が非常に困難になる可能性があります。システムの領域での初期の小さな競合により、チームメンバーは自分たちが行っている変更について連絡を取り合うようになります。[19]すべての変更を少なくとも1日1回(構築された機能ごとに1回)コミットすることは、通常、継続的インテグレーションの定義の一部と見なされます。さらに、通常、ナイトリービルドを実行することをお勧めします。[要出典]これらは下限です。通常の周波数ははるかに高いと予想されます。

(ベースラインへの)すべてのコミットを構築する必要があります

システムは、現在の作業バージョンへのコミットをビルドして、それらが正しく統合されていることを確認する必要があります。一般的な方法は、自動継続的インテグレーションを使用することですが、これは手動で行うこともできます。Automated Continuous Integrationは、継続的インテグレーションサーバーまたはデーモンを使用してリビジョン管理システムの変更を監視し、ビルドプロセスを自動的に実行します。

すべてのバグ修正コミットには、テストケースが付属している必要があります

バグを修正するときは、バグを再現するテストケースをプッシュすることをお勧めします。これにより、修正が元に戻されたり、バグが再表示されたりすることが回避されます。これは、リグレッションと呼ばれます。研究者は、このタスクを自動化することを提案しました。バグ修正コミットにテストケースが含まれていない場合は、既存のテストから生成できます。[20]

ビルドを高速に保つ

ビルドは迅速に完了する必要があるため、統合に問題がある場合はすぐに特定されます。

本番環境のクローンでテストする

テスト環境があると、実稼働環境がテスト環境と大幅に異なる可能性があるため、実稼働環境にデプロイするときにテスト対象システムで障害が発生する可能性があります。ただし、実稼働環境のレプリカを構築することは、法外なコストがかかります。代わりに、テスト環境、または別の実稼働前環境(「ステージング」)を構築して、テクノロジースタックの構成とニュアンスを維持しながら、コストを軽減する実稼働環境のスケーラブルなバージョンにする必要があります。これらのテスト環境では、サービスの仮想化は通常、依存関係(API、サードパーティアプリケーション、サービス、メインフレームなど)へのオンデマンドアクセスを取得するために使用されます、など)チームの制御が及ばない、まだ進化している、または仮想テストラボで構成するには複雑すぎる。

最新の成果物を簡単に入手できるようにする

関係者やテスターがビルドをすぐに利用できるようにすることで、要件を満たしていない機能を再構築するときに必要なやり直しの量を減らすことができます。さらに、初期のテストにより、展開まで欠陥が存続する可能性が低くなります。エラーを早期に発見することで、エラーを解決するために必要な作業量を減らすことができます。

すべてのプログラマーは、リポジトリからプロジェクトを更新することから1日を始める必要があります。そうすれば、それらはすべて最新の状態に保たれます。

誰もが最新のビルドの結果を見ることができます

ビルドが壊れているかどうか、壊れている場合は、誰が関連する変更を行ったか、その変更は何であったかを簡単に確認できるはずです。

展開の自動化

ほとんどのCIシステムでは、ビルドの完了後にスクリプトを実行できます。ほとんどの場合、誰もが見ることができるライブテストサーバーにアプリケーションをデプロイするためのスクリプトを作成することができます。この考え方のさらなる進歩は、継続的展開です。これは、ソフトウェアを本番環境に直接展開することを要求し、多くの場合、欠陥やリグレッションを防ぐために追加の自動化を行います。[21] [22]

費用と便益

継続的インテグレーションは、次のようなメリットを生み出すことを目的としています。

  • 統合のバグは早期に検出され、小さな変更セットにより簡単に追跡できます。これにより、プロジェクトの存続期間全体にわたって時間と費用の両方を節約できます。
  • 誰もがわずかに互換性のないバージョンをチェックインしようとするリリース日の土壇場の混乱を回避します
  • 単体テストが失敗したりバグが発生したりした場合、開発者がデバッグせずにコードベースをバグのない状態に戻す必要がある場合、失われる変更はごくわずかです(統合が頻繁に行われるため)
  • テスト、デモ、またはリリースの目的での「現在の」ビルドの継続的な可用性
  • コードを頻繁にチェックインすると、開発者はモジュール式で複雑でないコードを作成するようになります[要出典]

継続的な自動テストにより、次のようなメリットがあります。

継続的インテグレーションのいくつかの欠点には、次のものが含まれます。

  • 自動テストスイートの構築には、新機能をカバーし、意図的なコード変更に従うための継続的な取り組みを含む、かなりの量の作業が必要です。
  • ビルドシステムの設定にはいくつかの作業が必要であり、複雑になり、柔軟に変更することが困難になる可能性があります。[23]
  • プロジェクトの範囲が小さい場合やテストできないレガシーコードが含まれている場合、継続的インテグレーションは必ずしも価値がありません。
  • 付加価値は、テストの品質とコードが実際にどれだけテスト可能かによって異なります。[24]
  • チームが大きくなると、新しいコードが統合キューに絶えず追加されるため、(品質を維持しながら)配信を追跡することは困難であり、ビルドのキューイングによって全員の速度が低下する可能性があります。[24]
  • 1日に複数のコミットとマージを行うと、機能の部分的なコードが簡単にプッシュされる可能性があるため、機能が完了するまで統合テストは失敗します。[24]
  • 安全性とミッションクリティカルな開発保証(DO-178CISO 26262など)には、継続的インテグレーションを使用して達成するのが難しい厳密な文書化と進行中のレビューが必要です。このタイプのライフサイクルでは、製品の規制当局の承認が必要な場合、製品のリリース前に追加の手順を完了する必要があります。

も参照してください

参考文献

  1. ^ a b c ファウラー、マーティン(2006年5月1日)。「継続的インテグレーション」2014年1月9日取得
  2. ^ ブーチ、グレイディ(1991)。オブジェクト指向設計:アプリケーションを使用ベンジャミンカミングスp。209. ISBN 97808053009182014年8月18日取得
  3. ^ ベック、K。(1999)。「エクストリームプログラミングで変化を受け入れる」。コンピューター32(10):70–77。土井10.1109 /2.796139ISSN0018-9162_ 
  4. ^ Duvall、Paul M.(2007)。継続的インテグレーション。ソフトウェアの品質を向上させ、リスクを軽減します。アディソン-ウェスリー。ISBN 978-0-321-33638-5
  5. ^ ウォード・カニンガム(2009年8月5日)。「統合地獄」WikiWikiWeb 2009年9月19日取得
  6. ^ 「継続的インテグレーションとは何ですか?」アマゾンウェブサービス
  7. ^ Durieux、Thomas; アブレウ、ルイ; モンペラス、マーティン; Bissyande、Tegawende F。; クルス、ルイス(2019)。「TravisCIの3500万以上のジョブの分析」。2019 IEEE International Conference on Software Maintenance and Evolution(ICSME)IEEE:291–295。arXiv1904.09416Bibcode2019arXiv190409416D土井10.1109 /ICSME.2019.00044ISBN 978-1-7281-3094-1S2CID203593737 _
  8. ^ カイザー、GE; ペリー、DE; シェル、WM(1989)。Infuse:統合テスト管理と変更管理を融合します第13回国際コンピュータソフトウェアおよびアプリケーション会議の議事録。フロリダ州オーランド。pp。552–558。土井10.1109 /CMPSAC.1989.65147
  9. ^ ブーチ、グレイディ(1998年12月)。アプリケーションを使用したオブジェクト指向の分析と設計(PDF)(第2版)2014年12月2日取得
  10. ^ ベック、ケント(1998年3月28日)。「エクストリームプログラミング:ソフトウェア開発のヒューマニスティックな規律」ソフトウェア工学への基本的なアプローチ:最初の国際会議1.ポルトガル、リスボン:Springerp。4. ISBN 9783540643036
  11. ^ ベック、ケント(1999)。エクストリームプログラミングの説明アディソン-ウェスリープロフェッショナル。p。 97ISBN 978-0-201-61641-5
  12. ^ 「DevOpsの簡単な歴史、パートIII:自動テストと継続的インテグレーション」CircleCI2018年2月1日2018年5月19日取得
  13. ^ Sane、Parth(2021)、「継続的インテグレーションおよび自動アクセシビリティテストにおける現在のソフトウェアエンジニアリングプラクティスの簡単な調査」2021年第6回ワイヤレス通信、信号処理およびネットワーキングに関する国際会議(WiSPNET)、pp。130–134、arXiv2103.00097doi10.1109 / WiSPNET51692.2021.9419464ISBN 978-1-6654-4086-8S2CID  232076320
  14. ^ Brauneis、David(2010年1月1日)。「[OSLC]可能な新しいワーキンググループ–自動化」open-services.netコミュニティ(メーリングリスト)。2018年9月1日にオリジナルからアーカイブされました2010年2月16日取得
  15. ^ テイラー、ブラッドリー。「ShadowPuppetとCapistranoを使用したRailsのデプロイと自動化」Railsマシンワールドワイドウェブログ)。2012年12月2日にオリジナルからアーカイブされました2010年2月16日取得
  16. ^ たとえば「デバウンス」を参照してください。Arduino2015年7月29日。
  17. ^ ファウラー、マーティン「練習」継続的インテグレーション(記事)2015年11月29日取得
  18. ^ ラディガン、ダン。「継続的インテグレーション」アトラシアンアジャイルコーチ
  19. ^ 「継続的インテグレーション」Thoughtworks
  20. ^ ダンロット、ベンジャミン; モンペラス、マーティン; ルダメトキン、ウォルター; ベノワ・ボードリー(2020年3月5日)。「継続的インテグレーションにおけるコミットの動作の変化を検出するためのアプローチとベンチマーク」。経験的ソフトウェア工学25(4):2379–2415。arXiv1902.08482土井10.1007 / s10664-019-09794-7ISSN1382-3256_ S2CID67856113_  
  21. ^ Ries、Eric(2009年3月30日)。「5つの簡単なステップでの継続的展開」レーダーオライリー2013年1月10日取得
  22. ^ フィッツ、ティモシー(2009年2月10日)。「IMVUでの継続的展開:不可能なことを1日に50回実行する」Wordpress 2013年1月10日取得
  23. ^ ラウカネン、エエロ(2016)。「継続的デリバリーを採用する際の問題、原因、および解決策-系統的文献レビュー」情報およびソフトウェア技術82:55–79。土井10.1016 /j.infsof.2016.10.001
  24. ^ a b c デビッシュ、アダム。「ソフトウェア要件の内訳のコンテキストでの継続的インテグレーションの課題の評価:ケーススタディ」(PDF)

外部リンク