リリースサイクルの異なる多数のプラグインで構成される大規模なモジュラーUIアプリケーションを開発しています。 すべてのコードは1つのリポジトリにあるため、QAスペシャリストは常に開発者のもとに来て、次のように尋ねます。 タスクを確認するには、どのバージョンをアップロードする必要がありますか？」 質問は、UI（C＃）だけでなく、バックエンド（Java）にも関連することが判明しました。 すべてをペンで書くという無謀な約束の後、マージプルリクエストの時点で変更されたファイルに基づいて目的のリストを自動的に生成することを提案しました。 この記事では、サーバーの管理者権限と外部プラグインのインストールを行わずに、TeamCity（TC）のアセンブリ機能を拡張することにより、どのように組織化したかを説明します。
タスク条件
まず、ツールで何ができるかを判断しましょう。
- アセンブリが成功した場合、JIRAにアセンブリ番号を入力し、コメントに追加情報を示します（修復されたブランチ、展開するコンポーネントなど）。
- アセンブリが失敗した場合は、特定のテンプレートと問題の説明を含む特定の人に手紙を送ります。
これは次のようなものです。
次に、実装要件をリストします。
- アセンブリ後の重要なコード（ロジック）。
- WindowsおよびLinuxエージェントを使用します。
- エージェントの常識を覆すものはありません。
- ビルド構成で簡単に複製可能。
ソリューションを選択する
上記の要件の最初のポイントのため、TCでコマンドラインビルドステップを使用するオプションは不要になりました。
- これについて複雑なロジックを記述することは困難です（可能ですが）。
- bash / cmd / powershellを知っている専門家はほとんどいません。
- バージョン管理されていません。
- WindowsおよびLinuxエージェントで同じコードを実行することはできません。
そのため、maven-runnerによって起動されるmaven-pluginを作成することにしました。 アセンブルされたバージョンはバイナリストレージに保存され、ビルドプロセス中に直接ダウンロードされました。 アセンブリ中に毎回直接アセンブリすることができましたが、これによりアセンブリの実行時間が大幅に増加し、さらに、別のVCSルートへの依存が追加され、不必要なアセンブリにつながります。
または、目的のexeファイルでNuGetパッケージを作成し、プライベートNuGetサーバーからダウンロードして実行することもできます。 私たちの場合、Linuxサーバーのために、.NETプログラムのオプションは使用できませんでしたが、別のプロジェクトでは、このアプローチが適切であることが判明しました。
次に、多数のビルド構成のレプリケーションについて説明します。 2つの方法があります。
- ビルドテンプレート。 アセンブリはそこから継承できるため、さまざまなパラメーター/ステップ/プロパティを1か所で変更できます。
- メタランナー。 ランナーの下の模倣物は、アセンブリには一切表示されません。
この場合のビルドテンプレートは、使用するアセンブリが既にビルドテンプレートから継承されているため、あまり適していません。 また、この場合、現在のアセンブリに関係のない多くの詳細がステップ/プロパティに表示されます。
したがって、可能な技術的実装は次のようになります。
- プラグインのコードが保存される別のリポジトリが作成されます。
- プラグインは別のアセンブリにアセンブルされ、バイナリアーティファクト（NexusまたはArtifactory）のリポジトリに配置されます。
- ターゲットビルドの場合、このプラグインを創造的な方法で起動します。
- これらすべてをメタランナーとして作成します。
最も単純なMavenプラグイン
「com.db.meteor：jira-commenter」という最も単純なmaven-pluginを作成することから始めましょう。 これを行うには、次のようにAbstractMojoを継承します。
@Mojo( name = "stampJira", requiresProject = false) public class MainMojo extends AbstractMojo { @Parameter( property = "jiraCommenter.branch") public String branchName; public void execute() throws MojoExecutionException{ getLog().info(branchName); } }
以下は、mvnからパラメーターを渡す例です。 また、pom.xmlで、maven-plugin-pluginを使用してビルドする方法を示します。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-plugin-plugin</artifactId> <version>3.2</version> <configuration> <skipErrorNoDescriptorsFound</b>>true</<b>skipErrorNoDescriptorsFound> </configuration> <executions> <execution> <id>mojo-descriptor</id> <goals> <goal>descriptor</goal> </goals> </execution> </executions> </plugin>
プラグインの準備ができました。 次に、VCSへの変更を保存し、mvn：deployを作成する別のアセンブリを作成します。 これは簡単です。1つのビルドステップが必要です。
これで、maven-pluginをアセンブルしてローカルnexus（またはバイナリアーティファクトに使用するものに応じてアーティファクト）にアップロードする別のアセンブリができました。
TeamCityで起動
TeamCityでこのプラグインを実行して、正しい方向に進んでいることを確認します。 これを行うには、VCSルートを接続しない別のアセンブリを作成し、唯一のステップを追加します-mavenを起動します。ここで、ゴールにプラグインを指定し、パラメーターを渡します。
したがって、mavenを起動すると、適切な場所からプラグインがダウンロードされ、ローカルキャッシュに配置され、指定されたmojo（この場合はstampJira）が実行されます。
Maven 2では、バージョンとしてLATESTを指定できますが、3番目のバージョンから正確なバージョンを指定する必要があります。 アセンブリを実行し、プラグインがダウンロードされ実行されていることを確認します。
mavenを介してパラメーターを渡すのは不便ですが、幸いなことに、別の方法があります。 TeamCityにはREST APIがあります。 REST API自体は非常に強力であり、アセンブリ、エージェントなどに関するほとんどすべてを学ぶことができます。 これについては詳しく説明しませんが
、これには
優れた詳細なドキュメントがあります 。
以前は、アセンブリの現在のステータスと発生した問題（テスト/他の何か/ビルド出力）に関する情報を取得していました。 アセンブリ中、そのステータスはRUNNINGまたはFAILINGになり、それに基づいてアセンブリが成功したかどうかを判断します。
APIにアクセスするには、ユーザー名とパスワードが必要です。 アセンブリの開始時に、ワンタイムログインとパスワードが生成されるため、独自のものを使用しないでください。これらは、teamcityパラメーターで利用できます。
また、アセンブリのIDも必要です。同じ方法で渡します。
プラグインをJiraと統合して、そこに行き、必要なタスクを更新する価値があります。 これは記事の範囲を多少超えているため、ここでは詳しく説明しません。 このためにcom.atlassian.jiraライブラリを使用しました：jira-rest-java-client、stackoverflowでの使用例が多数あります。
メタランナーを抽出する
メタランナーの作成方法の例を示します。 まず、めったに使用されないメニュー項目を見つけて、新しいメタランナーの名前を考え出す必要があります。
抽出後、プロジェクトメタランナーのタブに表示されます。 必要に応じて、編集および更新できます。
技術的には、meta-runnerは実行するステップのxml記述であり、他のビルドステップと同様に利用可能です。 たとえば、私はこれを得ました：
<?xml version="1.0" encoding="UTF-8"?> <meta-runner name="Temporary for article"> <description>Temporary for article</description> <settings> <parameters> <param name="maven.security" value="%teamcity.agent.home.dir%/.m2/settings-security.xml" spec="text validationMode='any' display='hidden'" /> <param name="teamcity.build.branch" value="master" /> </parameters> <build-runners> <runner name="Launch Jira commenter." type="Maven2"> <parameters> <param name="goals" value="com.db.meteor.tools:jira-commenter:master-1.0.0.33:stampJira" /> <param name="maven.home" value="" /> <param name="mavenSelection" value="mavenSelection:default" /> <param name="runnerArgs" value="-DjiraCommenter.branch=%teamcity.build.branch%" /> <param name="teamcity.coverage.emma.include.source" value="true" /> <param name="teamcity.coverage.emma.instr.parameters" value="-ix -*Test*" /> <param name="teamcity.coverage.idea.includePatterns" value="*" /> <param name="teamcity.coverage.jacoco.patterns" value="+:*" /> <param name="teamcity.step.mode" value="default" /> <param name="userSettingsPath" value="%teamcity.agent.home.dir%/.m2/settings.xml" /> <param name="userSettingsSelection" value="userSettingsSelection:byPath" /> </parameters> </runner> </build-runners> <requirements /> </settings> </meta-runner>
必要に応じて、このようなXMLを自分で記述できますが、アセンブリから最初のXMLを取得する方が簡単です。 XMLを変更して、ここで編集できます。 たとえば、この方法でアセンブリのバージョンを変更します。
現在、現在のプロジェクトの任意のアセンブリに新しいビルドステップを追加できます。
さらに、テストアセンブリで使用されたパラメーターは、ビルド手順の入力に使用できるようになりました（例：teamcity.build.branch）。
さて、今、同僚や興味のあるすべての人に、このステップをアセンブリに追加し、人生を楽しむように頼むことができます。
注：meta-runner-aを抽出した後、抽出元のプロジェクトと同期しません。 したがって、何かを変更する場合は、変更してください。いつも走る？
ビルドが成功すると、コードが実行されます。 そして、アセンブリが失敗した場合はどうなりますか？ 詳細オプションには、「このステップをいつ実行するか」という便利なオプションがあります。
ここで、適切な実行条件が選択されます。 現在のタスクに対して、「前の手順の一部が失敗した場合でも」を設定します。
これがQAエンジニアの満足度を高める方法です。対応するタスクのマスターブランチまたはリリースブランチでの各マージリクエストの後に、変更内容とテスト用に展開する内容に関する詳細なコメントがJIRAに書き込まれます。