Jenkins、Gradle、およびArtifactoryを使用して、新しいビルド システムのプロトタイプを作成しています。ビルド アーティファクトとその宛先の指定に関して、これらのツールには競合する機能や重複する機能があるようです。私は、次の 3 つの道が進むと考えています。
- Jenkins Artifactory pluginを使用して、Jenkins の特定のタスクでアーティファクト設定を指定します。
- Gradle Artifactory pluginを使用して、Gradle ビルド スクリプトでアーティファクト設定を指定します。
- 標準のGradle "maven" pluginを使用して、Gradle ビルド スクリプトで一般的な Maven リポジトリ設定を指定します。
これらすべてのアプローチには賛否両論がありますが、私が見る限り、私たちのビルドにとって重要な機能が欠けているものはありません。
私の混乱をさらに深めるために、Gradle Artifactory プラグイン wikiには次のように記載されています。
ビルド サーバーの統合 - 継続的インテグレーション ビルド サーバーで Gradle ビルドを実行する場合は、Jenkins、TeamCity、または Bamboo 用の Artifactory プラグインのいずれかを使用して、ビルド情報をキャプチャする Artifactory への解決と公開をビルド サーバー UI 経由で構成することをお勧めします。
それで、会話を始めるためのいくつかの質問：
- ビルド スクリプトをアーティファクト ロジックで乱雑にすることは理にかなっていますか? その開発者がデプロイしないことを追加すると役立つ場合があります。現在、Jenkins タスクからアップロードされているビルド アーティファクトのみが表示されます。
- このビルド ロジックをすべてタスク構成に残すと、CI サーバーがダウンした場合に問題が発生する可能性がありますか?
- CI インターフェイスを介して行われたアーティファクトの変更のバージョン管理についてはどうですか?
- pom ではなく、CI サーバー UI を介してビルド アーティファクトを指定する単純な Bamboo 構成を見てきました。これは単に悪いビルド方法ですか?
- これらのアプローチの 1 つを他のアプローチから分離するキラー ツール統合機能はありますか?
- ビルド情報オブジェクトはどの程度役に立ちますか? それは Jenkins Artifactory プラグインでのみ利用でき、Gradle Artifactory プラグインでは利用できませんか?
これらのツールの既存のユーザーから、どのような落とし穴や要件が原因で上記のアプローチの 1 つ (あるいは、まだ検討していないより優れたアプローチ) に至ったのかを知りたいと思っています。