リリース自動化ツールJReleaserの1年前のビジョンが、それ自身のリリースを管理することだけであったとしたら、開発者のAndres Almiray氏も、カスタマベースがゆるやかに成長し、他プロジェクトのリリースを支える存在になるとは予想していなかったはずだ。Kafa Connet用コマンドラインクライアントのkcctlが、おそらくはJReleaserの最初のアーリーアダプタだろう。最近では、GuluonのSceneBuilderが、バイナリのアーリーアクセスリリース生成用のビルドパイプラインにJReleaserを加えた他、Quarkus CLIツールもHomebrewやSDKMAN!へのバイナリのパブリッシュに使用している。また、JReleaserの機能の多くにインスピレーションを与えたJBangも、JReleaserにスイッチした。
現在でもコードの95パーセントはAlmiray氏の書いたものだが、自身のプロジェクトにJReleaserを採用したコントリビューション開発者たちがディスカッショントピックやイシューやツイートなどの形で提供したフィードバックも、最新リリースであるJReleaser 1.0の機能形成に寄与している。プロジェクトのリリース管理にJReleaserを採用した場合のエクスペリエンスについて、より詳しく知るために、InfoQは今回、コントリビューションプロジェクトのいくつかに話を聞いた。
JBang + Quarkus CLI:
Red Hatのディスティングイッシュトエンジニア(distinguished engineer)であるMax Rydahl Andersen氏は、JBang 0.6でJReleaserを導入した他、最近ではQuarkus CLIにも採用している。そのリリースメカニズムが、JReleaserの最初のインスピレーションにもなったということもあって、JBangとの相性は極めて良好だった。その上、必要なオプションがすべて揃っていたということから、JReleaserの採用は理に適った選択だったのだ。JBangに特別なニーズがあったため、JReleaserの導入時には注意が必要だったが、そこから得られたフィードバックは、Andresen氏がJReleaserを改善するチャンスにもなった。この成果として、Quarkus CLIではまったく問題なく、JReleaserを導入することができたのだ。JReleaserは、GitHub Actionの最後にアーティファクトを受け取って、リリースに関するさまざまな作業を処理する。JReleaserの評価を尋ねた時、Andersen氏は次のように話してくれた。
よくできています。これまでのJavaエコシステムにはなかったものです。インストーラ間の違いを気にすることなく、自分のニーズに合わせた調整が可能です。Java CLIプロジェクトの90パーセントは、数分でセットアップを完了できるでしょう。
kcctl
Red HatのシニアプリンシパルソフトウェアエンジニアであるGunnar Morling氏は、JReleaserをいくつかのプロジェクトで使用しており、kcctlでJReleaser 0.6.0の最初のユーザ(icebreaker)になった。JReleaserを採用したことで、氏は、それまで面倒でカオスだったリリースケイデンスを、スムーズかつコンスタントなエクスペリエンスに置き換えることができた。その結果、3つの主流OS対応版を一度に公開することができたのだ。立ち上げフェーズ中は、Almiray氏がすべての不具合をすぐに修正して、新しいバージョンを提供してくれた。この最初の導入が容易であったことから、氏は自身の2つのプロジェクト — JFRUnitとoss-quickstartでもJReleaserを使うことにした。HomebrewとSDKMAN!を対象としたリリースに加えて、氏は将来的に、Chocolateyにもリリースできるようになることを希望している。JReleaserの評価について尋ねた時、氏は次のように答えてくれた。
[立ち上げの期間の対応は、]まるでプラチナサポートパッケージを入手したかのようでした。
Neo4j-OGM
Nao4JのスタッフソフトウェアエンジニアであるMichael Simons氏は、kcctlでの採用の成功を見て、Neo4j-OGMにJReleaser 0.8.0を導入した。Almiray氏が支援してくれたおかげで、立ち上げは午後半日も掛からずに完了した。詳細な資料にサポートされた妥当なデフォルト値によって、プラットフォーム固有の技術的問題はすべて舞台裏で解決されていた。もうひとつ驚いたのは、スタンドアロンでも他ツール(Mavenなど)のプラグインでも、ツールの使用方法に関わりなく、同じレベルの機能が利用可能であることだ。テンプレートメカニズムがあるので、リリースノートも、HomebrewやDockerなどのパッケージャへの統合も、すべてテンプレートを利用することができる。
もうひとつ重要な点は、JReleaserがフローにも簡単に適用可能であることだ。Simons氏の場合、Maven Centralへの公開に使用するMavenリリースプラグインを使って、リリースをローカルに行っている。ここでリリースタグを打つと、それによってGitHub Action上でJReleaserが起動される。これがリリースを生成し、ネイティブバイナリを(それにアタッチした)changelogとともにビルドして、JBangとHomebrewのカタログを更新してくれるのだ。JReleaserの評価を尋ねると、Simon氏は次のように答えてくれた。
実用的なchangelogの作成を最初から考えるならば、従来からあるコミットを利用すればよい、ということを、このツールが気付かせてくれました。
ConnectOffsetReset (ConnOR)
Predict8 GmbHのシニアソフトウェアエンジニアであるOliver Weiler氏は、ConnOR 0.5リリースの極めて初期の段階から、JReleaserの使用を始めている。ConnORは、Kafka Connectのソースコネクタオフセットをリセットする、小規模なCLIツールである。氏は自身のツールを、複雑な操作を必要とせずに、複数のチャネルに展開する方法を探していた。そうしたツールには、メリットよりも導入に伴う複雑さの方が大きいのではないか、という懸念も当初はあったが、JReleaserのデフォルトのおかげで、コンフィギュレーションに要する時間を短縮することができた。氏のプロジェクトは現在、Homebrew、SDKMAN!、Scoopを対象として展開されている。Weiler氏も述べているが、ドキュメントには改善の余地がある、というのが氏の意見だ。
よくできていますが、探しているものを見つけるのが難しい場合があります。それ以外は何の不満もありません。
JReleaserに関するエクスペリエンスについての質問には、次のように答えている。
GitHubにリリースしたい？ 設定を2行書くだけです！ Scoopに公開？ それも2行で終わります。まさに"設定より規約(convention over configuration)"そのものです！
JReleaserは、Almiray氏が自身のプロジェクトを通じて集めたプラクティスと、Javaコミュニティ内での議論の総和と言っていいだろう。その他にも、Almiray氏は、新たなプロジェクトへの導入の支援やバグ修正、新機能の追加などを行っている。いずれにせよ、Almiray氏が依然として中心的なコントリビュータであるとしても、Javaコミュニティが集結してフィードバックを提供したことが、JReleaserの継続的な改善に対して貢献していることに違いはない。