参考: 継続的インテグレーションプロセスの仕組み

今日は、この用語の歴史を振り返り、CI の実装の難しさについて説明し、CI の使用に役立ついくつかの一般的なツールを紹介します。

/フリッカー/ アルトゥグ・カラコック / CC BY / 写真修正済み

用語

継続的インテグレーションは、頻繁なプロジェクトのビルドとコードのテストを伴うアプリケーション開発のアプローチです。

目標は、統合プロセスを予測可能にし、潜在的なバグやエラーを早い段階で検出して、それらを修正する時間を増やすことです。

継続的インテグレーションという用語が初めて登場したのは 1991 年です。 UML言語の作成者によって導入されました グレイディ・ブッチ （グレイディ・ブーチ）。 このエンジニアは、自身の開発実践の一環として CI の概念を導入しました。 ブーチ法。 これは、オブジェクト指向システムを設計する際に、アーキテクチャを段階的に改良することを意味します。 Gradi 氏は、継続的統合の要件については何も説明していません。 しかし、彼の本の後半では、「アプリケーションを使用したオブジェクト指向の分析と設計同氏は、この方法論の目的は「内部リリース」のリリースを迅速化することであると述べた。

ストーリー

1996 年に、CI は方法論の作成者によって採用されました。 エクストリームプログラミング (XP) - ケント・ベック （ケント・ベック）と ロン・ジェフリーズ （ロン・ジェフリーズ）。 継続的インテグレーションは、彼らのアプローチの XNUMX の主要原則の XNUMX つになりました。 XP の創設者は、CI 方法論の要件を明確にし、プロジェクトを XNUMX 日に数回ビルドする必要があると指摘しました。

2000 年代初頭、Agile Alliance の創設者の XNUMX 人が継続的インテグレーション手法を推進し始めました。 マーティン・ファウラー （マーティン・ファウラー）。 彼の CI を使った実験は、この分野における最初のソフトウェア ツール、CruiseControl につながりました。 このユーティリティは Martin の同僚 Matthew Foemmel によって作成されました。

ツールのビルド サイクルは、バージョン管理システムでコード ベースの変更を定期的にチェックするデーモンとして実装されます。 このソリューションは今日からダウンロードできます - によって配布 BSD のようなライセンスの下で。

CI 用ソフトウェアの出現により、この慣行を採用する企業がますます増えました。 Forrester の調査によると [5 ページ 報告] によると、2009 年には調査対象となったテクノロジー企業 86 社のうち XNUMX% が CI 手法を使用または導入していました。

現在、継続的インテグレーションの実践は、さまざまな業界の組織で使用されています。 2018 年、大手クラウド プロバイダーは、サービス、教育、金融分野の企業の IT 専門家を対象に調査を実施しました。 回答者 58 人のうち、XNUMX% が仕事で CI ツールと原則を使用していると回答しました。

これはどう動かすのですか

継続的インテグレーションは、バージョン管理システムと CI サーバーという XNUMX つのツールに基づいています。 後者は、物理デバイスまたはクラウド環境の仮想マシンのいずれかになります。 開発者は XNUMX 日に XNUMX 回以上、新しいコードをアップロードします。 CI サーバーは、すべての依存関係とともにそれを自動的にコピーし、構築します。 その後、統合テストと単体テストが実行されます。 テストが成功すると、CI システムはコードをデプロイします。

一般的なプロセス図は次のように表すことができます。

CI 方法論では、開発者に次のような多くの要件が課されます。

• 問題をすぐに修正してください。 この原則はエクストリーム プログラミングから CI に生まれました。 バグの修正は開発者にとっての最優先事項です。
• プロセスを自動化します。 開発者とマネージャーは、統合プロセスのボトルネックを常に探して排除する必要があります。 たとえば、統合にはボトルネックが存在することがよくあります。 それが判明 テスト中。
• できるだけ頻繁に集会を開催します。 XNUMX 日に XNUMX 回、チームの作業を同期します。

実装の難しさ

第一の問題は、運営コストが高いことです。 企業がオープン CI ツール (これについては後で説明します) を使用している場合でも、インフラストラクチャのサポートに費用を費やす必要があります。 ただし、クラウド テクノロジーが解決策になる可能性があります。

これらにより、さまざまなスケールのコンピューター構成の組み立てが簡素化されます。 会社のプラス 支払われる 使用されたリソースのみが対象となるため、インフラストラクチャの節約に役立ちます。

調査によると[14ページ] 記事] のように、継続的インテグレーションは (少なくとも最初は) 従業員の負荷を増大させます。 彼らは新しいツールを学ばなければなりませんが、同僚が常にトレーニングを手伝ってくれるわけではありません。 したがって、新しいフレームワークやサービスにその場で対処する必要があります。

XNUMX 番目の困難は、自動化に関する問題です。 自動テストでカバーされていないレガシー コードを大量に抱える組織は、この問題に直面しています。 これにより、CI を完全に実装する前にコードが単純に書き直されることになります。

/フリッカー/ 彼ら / のCC BY-SA

誰が使うのか

IT 大手企業は、この方法論の利点を最初に認識した企業の XNUMX つです。 グーグル 使用する 2000 年代半ばからの継続的統合。 CI は、検索エンジンの遅延の問題を解決するために実装されました。 継続的インテグレーションは、問題を迅速に検出して解決するのに役立ちました。 現在、CI は IT 大手企業のすべての部門で使用されています。

継続的インテグレーションは中小企業にも役立ち、CI ツールは金融機関や医療機関でも使用されています。 たとえば、モーニングスターでは、継続的インテグレーション サービスにより、脆弱性へのパッチ適用が 70% 速くなりました。 また、Philips Healthcare 医療プラットフォームは、テスト更新の速度を XNUMX 倍にすることができました。

ツール

CI 用の一般的なツールをいくつか紹介します。

• ジェンキンズ は最も人気のある CI システムの 1 つです。 さまざまな VCS、クラウド プラットフォーム、その他のサービスとの統合用に XNUMX を超えるプラグインをサポートしています。 XNUMXcloud: ツールでも Jenkins を使用します。 DevOps システムに含まれる。 彼は、テスト用の Git ブランチを定期的にチェックアウトしています。
• ビルドボット — 独自の継続的統合プロセスを作成するための Python フレームワーク。 ツールの初期設定は非常に複雑ですが、これは幅広いカスタマイズ オプションによって補われます。 このフレームワークの利点の中でも、ユーザーはリソース集約度の低さを強調しています。
• コンコースCI は、Docker コンテナを使用する Pivotal のサーバーです。 Concourse CI は、あらゆるツールやバージョン管理システムと統合します。 開発者らは、このシステムはあらゆる規模の企業の作業に適していると述べています。
• Gitlab CI は、GitLab バージョン管理システムに組み込まれているツールです。 このサービスはクラウドで実行され、構成に YAML ファイルを使用します。 Concourse、Gitlab CI と同様 当てはまる さまざまなプロセスを相互に分離するのに役立つ Docker コンテナー。
• コードシップ は、GitHub、GitLab、BitBucket と連携するクラウド CI サーバーです。 このプラットフォームは長い初期セットアップを必要としません。標準のプリインストールされた CI プロセスが Codeship で利用可能です。 小規模 (月あたり最大 100 ビルド) のオープンソース プロジェクトの場合、Codeship は無料で利用できます。

当社の企業ブログからの資料:

• ファイルのバックアップ: データ損失を防ぐ方法
• 1cloud.ru の例を使用したクラウド サービスでの DevOps
• 組織のITインフラストラクチャのオプション

出所： habr.com