すぐに使用できるソフトウェア製品をリリースするには、コードを書くだけでは不十分です。 プログラマーが作業を完了した後、幅広いユーザーに製品を提示するのにかなりの時間がかかります。 まったく何もする必要がないように思われます。異なる開発者が作成したものをすべて組み合わせ、インストーラーを作成し、ドキュメントを準備します。 多くの場合、プログラマは、日常的な操作にかかる時間を想像することすらありません。 多くの場合、この状況が発生します。誰もが急いでいるため、エラーと欠点の数が増えるだけです。 欠陥の修正にも一定の時間が必要です。製品のリリースは無期限に延期する必要があります。
ソフトウェア製品は絶えず進化し、新しい機能で「成長」し、使いやすくなる必要があります。 しかし、プロジェクトの開発に伴い、通常、日常業務も多くなり、プロジェクトの改善について考える時間はまったくありません。
問題の状況は、私たちにとって身近なものです。 プログラマーがすべてのパッケージを手動で収集した時代がありました。 しかし、プロジェクトはますます多くなり、ルーチンの数は増えました。 しかし、製品の開発と改善について考える時間はますます少なくなりました。 何かを変える必要があり、継続的な統合を導入することを考えました。
継続的インテグレーションとは何ですか？
継続的インテグレーション（Engl。Continuous integration、略称CI）の概念は、2000年に同名のMartin Fowlerの記事で初めて使用されました。 この記事の定義によると、継続的インテグレーションはソフトウェア開発の実践であり、プロジェクトの頻繁なアセンブリを実行して、初期段階で問題やエラーを迅速に特定します。
継続的な統合は、次の原則に基づいています。
- 各変更を統合する必要があります。コードに変更を加えるたびに、新しいアセンブリが起動します。 この原則を順守することにより、常に最新バージョンの製品を手に入れることができます。
- 組み立てはできるだけ早くする必要があります。 継続的インテグレーションの実装に関する記事では、次の数値が見つかる場合があります。標準アセンブリは10分以上かかることはありません。 実際、継続的インテグレーションのポイントは、迅速なフィードバックを得ることです。
- テストは定期的に行う必要があります。これにより、すべてのエラーを迅速に検出して修正できます。
- 統合は特別なマシンで実行する必要があり、その構成はプロジェクトを展開する環境に対応しています。 専用マシンでなければなりません（仮想マシンでもかまいません）。
これらすべての原則を実践することで何が得られるでしょうか？
第一に、さまざまなプログラマーによって行われた変更および変更の問題を解決するために、すべてが自動的に行われます。
第二に、継続的インテグレーションにより、プログラマーの結果を公平に評価することが可能になります。ビルドサーバーで何かが機能しない、つまりまったく機能しないということです。
第三に、定期的なテストにより、製品の品質を適切なレベルに維持できます。
CIを実際に実装するには、さまざまな要因を考慮する必要があります。 重要なポイントは、CIのソフトウェアソリューションの選択です。 完全に自分に合ったオプションを見つける前に、いくつかの製品を試しました。
CIシステムの選択
使用を試みた最初の継続的統合ツールはAtlassian Bambooでした。 その頃には、すでにアトラシアンJIRAを積極的に使用しており、Bambooを支持する主な論点は、ユーザーインターフェイスの統一と他のアトラシアンサービスとの統合の容易さでした。
Bambooを導入する前は、プログラマーは自分の手で多くのことを行わなければなりませんでしたが、それはプログラミングとは異なり、多くの時間を要しました。ここでは主にパッケージの手動組み立てとテストについて説明します。 Bambooの助けを借りて、アセンブリを自動化して時間を節約することを期待していましたが、残念ながら、これはうまくいきませんでした。 Bambooを使用しようとしたときの欠点の1つは、構成ルーチンでした。これは、プログラマ自身が手動アセンブリに戻るのに非常に時間がかかる場合があり、より便利でした。 したがって、このツールは私たちに定着しませんでした。
次に、オープンソースのJenkinsツールを実装しようとしましたが、いくつかの深刻な問題に直面しました。 すぐに目を引くのは、不便なインターフェースや過度の構成の複雑さなどの短所です。 作業の過程で、さらに重要なマイナスが明らかになりました。 実際、元の初期設定では、Jenkinsの機能は非常に制限されています。 機能の範囲は、さまざまなプラグインで拡張されます。 しかし、これらのプラグインは常に良質ではなく、非常に頻繁に相互に競合し、これも多くの問題を引き起こします。
Jenkinsで説明されているすべての困難のため、プログラマーは「行きませんでした」と呼ばれるものも持っています。 ただし、クラウドサーバー部門では、カーネルの再構築と機能テストにまだ使用されています。
さらなる検索で適切なCIツールが見つかりました。これは、JetBrains製品のTeamCityです。 間違いない利点は次のとおりです。
- セットアップと管理のシンプルさ。
- 標準として、「箱から出してすぐに」かなり大きな機能セット。
- さまざまな開発環境と統合する機能。
- 使用しているアトラシアン製品（JIRAおよびConfluence）と統合する機能。
- テンプレートプロジェクトの存在;
- 非常に柔軟なライセンス条項。
興味深いことに、TeamCityは同じアプローチに基づいており、これがジェンキンスからの理由の1つになりました。機能セットの拡張もプラグインを使用して実行されます。 ただし、前述のように、Team Cityは基本構成で非常に多くの機能を備えているため、あらゆる場合にプラグインをインストールする必要はありません。 私たちが対処しなければならなかったこれらのいくつかのプラグインは、かなり安定して動作しました。 TeamCityのもう1つの重要な利点は、人間工学と使いやすさです。
結論の代わりに
図と事実の言語での継続的な統合の導入の結果として得られた利点を説明してみましょう。 チームシティを使用するすべての時間の統計は次のとおりです。
- 102プロジェクト;
- 280アセンブリ;
- 320 GBのアーティファクト。
- 毎週約1,000の新しいビルドが実行されます。
日常業務の自動化の結果、週に約33時間を節約できました。 リリースされた時間は、既存のサービスの開発と改善、および新しいサービスの導入に充てられます。
Habréの投稿にコメントできない場合は、 ブログに招待します。