/ Flickr / Altug Karakoc / CC BY /写真が変更されました
期間
継続的インテグレーション-プロジェクトの頻繁なアセンブリとコードのテストを含む、アプリケーション開発へのアプローチ。
目標は、統合プロセスを予測可能にし、潜在的なバグとエラーを早期に検出して、修正する時間を増やすことです。
継続的インテグレーションという用語は、1991年に初めて登場しました。 UML言語の作成者であるGrady Boochによって導入されました。 エンジニアは、彼自身の開発プラクティスの一部として、ブッチ法というCIコンセプトを導入しました。 これは、オブジェクト指向システムを設計するときに、アーキテクチャの漸進的な改良を意味していました。 Gradyは、継続的統合の要件については説明しませんでした。 しかし、彼の著書「 アプリケーションを使用したオブジェクト指向分析と設計 」の後半で、方法論のタスクは「内部リリース」のリリースを加速することであると述べました。
物語
1996年、CIはExtreme Programming Methodology（XP）の作成者であるKent BeckとRon Jeffriesによって採用されました。 継続的インテグレーションは、アプローチの12の重要な原則の1つになりました。 XPの創設者は、CI方法論の要件を明確にし、プロジェクトを1日に数回組み立てる必要があると指摘しました。
2000年代初頭、アジャイルアライアンスの創設者の1人であるMartin Fowlerは 、継続的インテグレーションの方法論を促進し始めました。 CIでの彼の実験は、業界初のソフトウェアツールであるCruiseControlにつながりました。 このユーティリティは、Martinの同僚であるMatthew Foemmelによって作成されました。
ツールのビルドサイクルはデーモンとして実装され、コードベースの変更についてバージョン管理システムを定期的にチェックします。 ソリューションは今日ダウンロードできます-BSDライクなライセンスの下で配布されています。CI用のソフトウェアの出現により、ますます多くの企業がこのプラクティスを採用し始めました。 Forresterの調査[ レポートの 5ページ]によると、2009年に調査した50のテクノロジー企業の86％がCIメソッドを使用または実装しました。
現在、継続的インテグレーションは、さまざまな業界の組織によって実践されています。 2018年に、主要なクラウドプロバイダーが、サービス、教育、および金融セクターの企業のIT専門家を対象に調査を実施しました。 6,000人の回答者のうち、58％が仕事でCIツールと原則を使用していると答えました。
仕組み
継続的統合の基盤は、バージョン管理システムとCIサーバーの2つのツールです。 後者は、クラウド環境の物理デバイスまたは仮想マシンのいずれかです。 開発者は新しいコードを1日に1回または数回アップロードします。 CIサーバーは、すべての依存関係とともにそれを自動的にコピーし、アセンブリを実行します。 後-統合および単体テストを起動します。 テストが成功すると、CIシステムはコードを展開します。
プロセスの一般的なスキームは、次のように表すことができます。
CI方法論には、開発者にとって多くの要件があります。
- 問題をすぐに修正します。 この原則は、極端なプログラミングからCIにもたらされました。 バグ修正は開発者にとって最優先事項です。
- プロセスを自動化します。 開発者と管理者は、統合プロセスで常に「ボトルネック」を探して排除する必要があります。 たとえば、多くの場合、テストは統合のボトルネックです。
- できるだけ頻繁にビルドします。 1日1回、チームの作業を同期します。
実装の難しさ
最初の問題は、運用コストが高いことです。 たとえ会社がオープンCIツール（後で説明します）を使用していても、インフラストラクチャのサポートにお金を費やす必要があります。 ただし、クラウドテクノロジーが解決策となる場合があります。
マルチスケールコンピューター構成のアセンブリを簡素化します。 さらに、企業は使用したリソースに対してのみ料金を支払うため、インフラストラクチャの節約に役立ちます。
調査[ 記事のp。14 ]によると、継続的な統合は（少なくとも初めて）会社の従業員の負担を増やします。 彼らは新しいツールを学ぶ必要があり、同僚が常にトレーニングを手伝うわけではありません。 したがって、外出先で新しいフレームワークとサービスに対処する必要があります。
3番目の問題は、自動化の問題です。 自動化されたテストでカバーされていない大量のレガシーコードを持つ組織が直面しています。 これは、CIの完全な実装の前にコードが単純に書き換えられるという事実につながります。
/ Flickr / theilr / CC BY-SA
使用者
この方法論の最初の利点の1つは、ITの巨人に高く評価されました。 Googleは2000年代半ばから継続的インテグレーションを使用しています。 検索エンジンの遅延の問題を解決するために実装されたCI。 継続的な統合は、問題の迅速な特定とトラブルシューティングに役立ちました。 現在、CIはIT大手のすべての部門で使用されています。
継続的インテグレーションは中小企業にも役立ち、CIツールは金融機関や医療機関でも使用されています。 たとえば、モーニングスターでは、継続的インテグレーションサービスにより、パッチの脆弱性が70％速くなりました。 また、フィリップスヘルスケアの医療プラットフォームは、テストの更新速度を2倍にすることができました。
ツール
CIの一般的なツールは次のとおりです。
- Jenkinsは最も人気のあるCIシステムの1つです。 さまざまなVCS、クラウドプラットフォーム、およびその他のサービスと統合するために、1,000以上のプラグインをサポートしています。 Jenkinsは1cloudでも使用しています。このツールはDevOpsシステムに含まれています 。 彼はテストのためにGitブランチを定期的にチェックしています。
- Buildbotは、独自の継続的統合プロセスを記述するためのpythonフレームワークです。 ツールの初期セットアップは非常に複雑ですが、これはカスタマイズの幅広い可能性によって相殺されます。 フレームワークの利点の中で、ユーザーはリソースの強度が低いことを区別します。
- Concourse CIは、Dockerコンテナーを使用するPivotalのサーバーです。 Concourse CIは、あらゆるツールおよびバージョン管理システムと統合します。 開発者は、このシステムはあらゆる規模の企業での作業に適していると指摘しています。
- Gitlab CIは、GitLabバージョン管理システムに組み込まれているツールです。 サービスはクラウドで実行され、構成にYAMLファイルを使用します。 Concourseと同様に、Gitlab CI は異なるプロセスを相互に分離するのに役立つDockerコンテナーを使用します。
- コードシップは、GitHub、GitLab、およびBitBucketで動作するクラウドベースのCIサーバーです。 このプラットフォームでは、長い初期設定は必要ありません。標準の事前定義されたCIプロセスはCodeshipで利用できます。 小規模（1か月あたり最大100ビルド）およびオープンソースプロジェクトの場合、Codeshipは無料で利用できます。