PVS-Studio開発チームでCruiseControl.NETからJenkinsに切り替える

今では、自動化されたプロジェクトのアセンブリとテストなしのソフトウェア開発を想像するのは困難です。 開発者の変更をプロジェクトに統合するのにかかる時間を最小限に抑えるために、さまざまな既製のソリューションがあります。 この記事では、PVS-Studio開発チームでCruiseControl.NET継続的統合サーバーをJenkinsに置き換えることについて説明します。 また、これを私たちに促したもの、追求した目標、直面した問題についても。

はじめに

継続的インテグレーション（Eng。継続的インテグレーション、以下CIと呼びます）は、開発されたソフトウェアを組み立て、展開、テストする自動プロセスです。 この開発手法は、大規模なチームでも個人の開発者でも人気があります。 このプラクティスには多くの既成のソリューションがあります。 この記事では、CruiseControl.NETとJenkinsの無料のオープンソースプロジェクトについて説明します。



CruiseControl.NET （CCNet）は、.NET Frameworkに実装された継続的なソフトウェア統合のためのツールです。 Javaツールオプション（CruiseControl）とRuby環境バージョン（CruiseControl.rb）もあります。 アセンブリに関する情報の管理と表示は、Webインターフェイスまたはデスクトップユーティリティを介して実行されます。 さまざまなバージョン管理システムと統合します。 これはオープンソースプロジェクトであり、残念ながら2013年頃から開発されていません。



Jenkinsは、Javaで記述されたオープンソースの継続的統合ツールです。 Oracleとの論争の後、 ハドソンプロジェクトから分岐しました。 継続的な統合機能を提供することにより、ソフトウェア開発プロセスの一部を自動化できます。このプロセスでは、人間の参加は不要です。 Jenkinsの機能はプラグインで強化できます。 現時点では、プロジェクトは開発者とコミュニティの両方によって積極的に開発およびサポートされています。



この記事はCCNet対スタイルレビューに少し似ていますが Jenkins」、フォーカスはすぐにJenkinsでサーバーを選択することになります。 継続的統合ツールを変更する主な理由は、CruiseControl.NETプロジェクトの開発の不足です。 また、この記事では、困難が生じたCCNetでの作業の他の側面についても説明します。



最近、PVS-Studioプロジェクトには10​​年の記念日がありました。これは、「 PVS-Studioプロジェクトが10年前にどのように始まったのか 」という記事にあります。 製品の寿命の半分以上の間、CCNetを使用しています。 そのインターフェイス、設定、機能は非常に馴染みのあるものになったため、ジェンキンスは非常に不快に感じました。 Linux向けPVS-Studioが登場したときに最初に使用を開始しました。 Jenkinsへの移行の前に、このツールの長い研究が行われました。 CCNetの使い慣れた機能の類似物を探すのに費やした時間の一部。 次に、完了した作業の興味深い点について説明します。

CCNetに対する当社の主張

1. CCNetは現在開発されていません。 それでも使用できますが、機能を拡張し、既存の/潜在的なエラーを修正するには、独自にそれを行う必要があります。
2. 変更のSCM（ソースコード管理）ポーリングモードは不安定です。つまり、バージョン管理システムに変更がある場合の自動起動です。 ネットワークに問題がある場合、このモードでは、プロジェクトが開始していなくても、プロジェクトのステータスは「失敗」になります。 実際には、問題が頻繁に発生するため（残念ながら、当社のオフィスには最も安定したインターネットアクセスがありません）、このモードを使用できなくなります。
3. バージョン管理システムでエラーが発生した場合（たとえば、設定で指定されたディレクトリがリポジトリから削除され、ツリーの競合が発生した場合）、変更についてSCMに問い合わせると、プロジェクトはすぐに中断され、成功ステータスを維持します-プロジェクトは動作を停止しますただし、ウェブインターフェースとデスクトップユーティリティのステータスは「グリーン」のままです。 このモードでは、たとえば、テストの起動に数週間はかからない場合があり、テストが正常に機能していると考えて誰もそれに注意を払わないというリスクがあります。
4. 一般的なサーバー操作ログは冗長すぎて構造化されていません。どのアセンブリステップが落ちたかを理解し、この特定のステップのログを見つけることは困難です。 複数のプロジェクトが並行して動作する場合、ビルドログは「混合」されます。 1つのプロジェクトのXMLビルドログはWebインターフェースで利用できますが、逆に詳細が不十分であることが多く、実行されるすべてのコマンドが含まれていません。
5. プロジェクト内のサブタスクの非効率的な並列化。 サブタスクは、プロセッサコアの数ごとにグループで並列に実行されます。 長くて速いタスクがグループに分類される場合、前回の起動からのすべてのタスクが完了するまで、新しいタスクは起動されません。

ユースケース比較

サーバー設定

CCNetプロジェクト設定（サーバー構成）は1つのxmlファイルに保存され、別のパスワードは別のファイルに保存されました。 設定ファイルは約4,500行に達しましたが、使用すると非常に便利でした。 メモ帳++でAlt + 2を軽く押すと、すべてのプロジェクトのリストを折りたたみ、必要に応じて編集できます（図1）。

図1-メモ帳++でのCCNet設定の編集



ファイルには重複したコードが含まれていましたが、サーバーサポートに特別な問題はありませんでした。



これはSCMブロックがどのように読み込まれるかです：

<svn> <username>&SVN_USERNAME;</username> <password>&SVN_PASSWORD;</password> <trunkUrl>&SVN_ROOT;...</trunkUrl> <workingDirectory>&PROJECT_ROOT;...</workingDirectory> <executable>&SVN_FOLDER;</executable> <deleteObstructions>true</deleteObstructions> <cleanUp>true</cleanUp> <revert>true</revert> <timeout units="minutes">30</timeout> </svn>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、MSBuildブロックが追加されました。

 <msbuild> <description>PVS-Studio 2015</description> <workingDirectory>&PROJECT_ROOT;...</workingDirectory> <projectFile>...\PVS-Studio-vs2015.sln</projectFile> <buildArgs>/p:Configuration=Release</buildArgs> <targets>Build</targets> <timeout>600</timeout> <executable>&MSBUILD14_PATH;</executable> </msbuild>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ブロックは一般的なタスクのために埋められました：

 <exec> <description>PVS-Studio 2015 sign</description> <executable>&PROJECT_ROOT;...\SignToolWrapper.exe</executable> <baseDirectory>&PROJECT_ROOT;...</baseDirectory> <buildArgs>"&SIGNTOOL;" ... \PVS-Studio-vs2015.dll"</buildArgs> <buildTimeoutSeconds>600</buildTimeoutSeconds> </exec>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなプロジェクトファイルに基づいて、CCNetは実行されたすべての手順を便利に表示します（ただし、デスクトップトレイユーティリティでのみ。何らかの理由で、Webインターフェイスはこれをサポートしませんでした）。 Jenkinsでは、統合プロジェクトの段階を「高レベル」に表示するため、いじくり回す必要がありましたが、後で説明します。



Jenkinsの場合、サーバー構成、一部のプラグインの構成ファイル、各プロジェクトには独自の構成ファイルがあります。 これらのファイルはすべてxml形式で指定されていますが、（少なくともCCNetと比較して）表示および編集にはあまり便利ではありません。 タグ内のすべてのコマンドはソリッドテキストで書かれています。 確かに、これは主にツールを使用するイデオロギーによるものです。 CCNetでは、構成は手動で書き込まれるため、「美しく」フォーマットできます。 ただし、Jenkinsでは、Webインターフェイスを使用してプロジェクト設定を編集し、構成を自動的に生成します。



これは、Jenkins構成のコマンドがどのように見えるかです：

 <hudson.tasks.BatchFile> <command>CD &quot;%BUILD_FOLDERS%\Builder&quot;&#xd; PVS-Studio_setup.exe /VERYSILENT /SUPPRESSMSGBOXES ...&#xd; Publisher_setup.exe /VERYSILENT /SUPPRESSMSGBOXES</command> </hudson.tasks.BatchFile>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは非常に小さな例です。

タスクのステータスを表示する

前に書いたように、CCNetでは、プロジェクトにタスクブロックが入力されます。 これは、正常に完了したタスクが表示されたステップのようです（図2）。

図2-CCTrayでのタスクステータスの表示（CCNetのデスクトップクライアント）



ブロックのいずれかのエラーは、サブタスクの階層にはっきりと表示されます。 これは、統合プロセスの非常に便利で視覚的な視覚化です。 タスクの説明によれば、ログを探す必要はほとんどありませんでした。ローカルコンピューターで確認する価値があることがすぐにわかりました。 Jenkinsでは、この形式で直接何も見つかりませんでした。したがって、新しいサーバーに移動する前に、この瞬間を詳細に調査する必要がありました。



CCNetとJenkinsの類似点を描くことができます。CCNetにはプロジェクトがあり、このプロジェクトのステップはタスクです（上の図を参照）。 Jenkinsにもプロジェクト（ジョブ）があり、その手順は手順です（図3）。

図3-CCNetとJenkinsでのプロジェクトの命名の対応



残念ながら、Jenkinsのウェブインターフェースでは個々のステップの動作を視覚化することはできません。ジョブには、すべてのステップをまとめた完全なコンソールログしかありません。 ここでの大きな不便は、どのステップが失敗したかをJenkinsから見ることができないことです。完全なジョブアセンブリログを確認する必要があります。 そして、あなたはすぐに良いことに慣れるので、古いユースケースを拒否したくありませんでした。 それからMultijobプラグインが助けになりました 。



このプラグインにより、次の革新を行うことができました。



1.他のジョブのステップとしてジョブを使用する。 したがって、ユニバーサルジョブが登場しました。これにより、特定のサブタスクのログを分離し、最も重要なこととして、特定のサブタスクのステータスを個別に表示できました。 Jenkins Webインターフェースは、マルチジョブ内の個々のジョブの実行を視覚化できます-まさに私たちが探していたものです。 図4は、完成したマルチジョブの例を示しています。

図4-完了したMultijob'aの表示



2.ユニバーサルジョブを使用すると、重複するコードを取り除くことができました。 たとえば、配布キット、テストの実行、コード分析の開始など、いくつかのユーティリティのコンパイルがあります。 CCNetでは、これらは3つの異なるプロジェクトの同じタスクブロックでした。 Jenkinsには、このユーティリティをコンパイルするためのJobがあり、複数のMultijobで使用されています。



3. Jenkinsでプロジェクトを作成する場合、次のイデオロギーが使用されます。 マルチジョブ「プロジェクト」およびユニバーサル「ステップ」で共有するすべてのジョブ。 ユニバーサルジョブの名前には接頭辞「job_」が付いており、独立したプロジェクトとしての使用を意味するものではありません。 また、リポジトリからソースコードをダウンロードすることも含まれていません。 マルチジョブ名には「proj_」という接頭辞が付いており、ソースコードの読み込み、および他のジョブの起動のみが含まれます。 （視覚化されていないため、回避しようとするステップ）。



ユニバーサルジョブは、次のパラメーターで起動されます。

 WORKSPACE=$WORKSPACE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ジョブがマルチジョブの作業ディレクトリで起動されることを意味します。



したがって、ソースファイルの更新ログとアセンブリのすべての段階のログを別々に取得することができます。 すべてのプロジェクトでこのイデオロギーに従うことは難しく、無意味です。 これは、問題が発生した場合に詳細に調査する必要があるいくつかの最大かつ最も重要なプロジェクトに対してのみ行われます。



4.マルチジョブでは、ジョブの条件付きおよび並列実行を構成できます。 マルチジョブは、同じルールに従ってマルチジョブを実行できます。 したがって、プロジェクトの起動を組み合わせることができます。たとえば、すべてのインストーラーまたはすべてのテストのアセンブリを実行します。

ビルドログを表示する

CCNetでは、プロジェクトのビルドログを表示するのは非常に不便でした。 サーバーの出力と混同し、特別なマークアップがありました。 Jenkinsにはこのような問題はありません。さらに、一部のプロジェクトではサブタスクのログを分割することが可能になりました。

ソースコードリビジョンの取得

Jenkinsは、SVNリポジトリに追加された各リンクのリビジョンバージョンを定義します。 つまり 複数のディレクトリを追加する場合、番号は大きく異なる可能性がありますが、最大数が1つ必要です。



ドキュメントに従って、これを次のように操作します。



複数のモジュールをチェックアウトしている場合は、svnversionコマンドを使用します。 複数のモジュールをチェックアウトしている場合は、svnversionコマンドを使用してリビジョン情報を取得するか、SVN_REVISION_ <n>環境変数を使用できます。<n>は設定された場所に一致する1から始まるインデックスです。



そして、彼らはそれを行いました。すべての設定値SVN_REVISION_ <n>から最大値が取得され、アセンブルされたプログラムに追加されます。

Jenkinsの便利なプラグイン

プラグインを使用して機能を拡張すると、サーバーをできるだけ柔軟に構成できます。 Visual Studioでテストを実行するためのプラグインは、おそらく使用を拒否した唯一のプラグインです。 これらには、使用しない必須の起動パラメーターが追加されていたため、コマンドラインからテストを実行するだけで、ユニバーサルジョブを作成する方が簡単でした。 残念ながら、箱から出してすぐに、ジェンキンスは私たちがCCNetで慣れているものの多くを知りませんでした。 しかし、プラグインの助けを借りて、必要なすべての機能を「戻す」ことができました。



以下は、使用するのに便利であるとわかった簡単な説明付きのプラグインのリストです。

1. マルチジョブプラグイン -他のジョブをアセンブリの段階として使用して、順次および並列実行の可能性を持たせることができます。
2. Environment Injectorプラグイン -このプラグインを使用すると、グローバルパスワードを設定できます。 これらは環境変数として使用されますが、プラグインはそのような変数の値をログに隠します。
3. Pre SCM BuildStep Plugin-バージョン管理システムのコマンドを実行する前に追加のステップを追加します。
4. MSBuildプラグインは、MSBuildを使用してプロジェクトを構築するための便利なプラグインです。 設定では、MSBuildの異なるバージョンへのパスが一度示されます。 さらにプロジェクトでは、アセンブリ手順を簡単に追加できます。
5. パラメーター化されたトリガープラグイン -プロジェクトの起動オプションを追加します。 たとえば、ディストリビューションを構築するためのトランク/安定ブランチを選択できます。
6. ビルド後スクリプトプラグイン -アセンブリ後に追加の手順を実行します。
7. Throttle Concurrent Buildsプラグイン -このプラグインを使用すると、プロジェクトの並列ビルドの数をグローバルに、または特定のカテゴリ内で調整できます。 JenkinsのCCNetのキューに似た機能を取得できます。異なるカテゴリ（キュー）の複数のプロジェクトを並行して実行できる一方で、単一のキュー内でプロジェクトを順次実行できます。 たとえば、インストーラー（ディストリビューション）とテスト（テスト）のキューがあります。 テストの実行中にある種の配布キットを収集できるようにしたいのですが、同時にテストが並行して動作しないようにする必要があります-サーバー上に十分なカーネルがありません。
8. Build Name Setter Plugin-必要な形式（ Major.Minor.Revision.Build）でアセンブリ名を設定できます。
9. ダッシュボードビュー -ブラウザにジョブの独自の表示を追加できます。 なぜなら 手動で実行する意味がない汎用ジョブがあるため、このプラグインを使用せずにリストを作成しました。
10. ZenTimestampプラグインは、タイムスタンプを追加してログを作成する便利なプラグインです。

デスクトップクライアントの概要

CCNetから通知を受信するために、Windows用クライアント-CCTrayを使用しました。



Jenkinsを操作するためのいくつかのオプションを次に示します。



1. CCTray-このプログラムは、Jenkinsのサーバーにも使用できます。 プロジェクトは以前とほぼ同じになります（図5）。

図5-CCTrayのスクリーンショット



Jenkinsの顧客としての説明：

• CCNetのようには開発されません。
• サブタスクを表示する方法がわかりません（CCNetでのみ機能します）。
• プロジェクトの実行方法がわかりません。
• 名前をクリックすると、プロジェクトページに移動できます。
• プロジェクトの表示タイプ（アイコン、リスト、詳細）が調整されます。
• オープンソース。

2. CatLight （図6）

図6-CatLightのスクリーンショット



お客様の説明：

• 現時点では、ベータ版、最終版が支払われます。
• インターフェイスのインストール、操作、グリッチ中にクラッシュが発生します。
• コンピューターが休止状態から解除されると、ダッシュボード上のプロジェクトのステータスは自動的に更新されません。
• マルチジョブのサブタスクを表示する方法がわかりません。
• プロジェクトの実行方法がわかりません。
• プロジェクトの表示タイプは構成されていません（可能なビューは図6のみです）。
• 名前をクリックすると、プロジェクトページに移動できます。
• 最後の5つの開始のステータスを確認して、それらにアクセスできます。
• 起動したプロジェクトの進行状況を確認できます。
• 複数のサーバーを追加する場合は、ダッシュで区切ってください。
• Windows、Linux、Mac用があります。

3. 加藤 （図7）

図7-加藤のスクリーンショット



お客様の説明：

• マルチジョブのサブタスクを表示する方法がわかりません。
• プロジェクトを開始できます。 残念ながら、パラメータ化された起動を伴うプロジェクトはサポートされていません-そのようなプロジェクトを起動しようとするとユーティリティがクラッシュします。
• 異なるサーバーのプロジェクトは1つのリストに表示され、区別できません（必ずしも便利ではありません）。
• プロジェクトの表示タイプ（リスト、グリッド）が調整されます。
• 名前をクリックすると、プロジェクトページに移動できます。
• クライアントで最後のログを直接表示できますが、等幅のテキストがないため、これはあまり便利ではありません。
• オープンソース。
• Windowsのみ。

4. CCMenuは、オープンソースのMac専用クライアントです。 私たちにとっては関係ありませんが、誰かにとっては便利かもしれません。

おわりに

CIの使用は、あらゆるプロジェクトで役立ちます。 これを行うために、素晴らしい無料ツールJenkinsがあります。これは、記事で説明したほか、他の多くの無料および有料のCIです。 開発プロジェクトを使用するのは良いことです。Jenkinsとプラグインについては、定期的に多くの更新が公開されます。 たとえば、まだベータ段階にある新しいBlue Oceanプロジェクトがメインページにあるなど、新しいソリューションが登場しています。



Jenkinsプロジェクトを監視するクライアントは、私をあまり喜ばせませんでした。 多くの機能要求が欠落しています。 おそらくデスクトップクライアントは特に需要がなく、Webインターフェイスのみを使用する方がより適切です。



新しいサーバーに移動するとき、JenkinsをWindowsサービスとして使用できませんでした。なぜなら、 このモードではUIテストは実行されません。 隠されたウィンドウを持つコンソールアプリケーションとして起動するようにサーバーを構成することで、状況から抜け出しました。



提示された資料への追加またはこれらの問題に対する興味深い解決策がある場合は、記事にコメントを残すか、フィードバックフォームからご連絡ください。





英語を話す聴衆とこの記事を共有したい場合は、翻訳へのリンクを使用してください：Svyatoslav Razmyslov。 CruiseControl.NETからPVS-Studio開発チームのJenkinsへの移行