GradleGradle用のsemantic-releaseプラグインはJavaでsemantic-releaseを再実装したものしか無かったので、TypeScriptで書いたものを作りました。叩くだけのシンプルなものですが、CI周りの設定はGradle側に寄せてあるはずなのでこれで問題なく運用できます。バージョンをgradle.propertiesで管理する必要がある点にのみ注意してください。travis-ci最近Java周りでもsemantic-releaseの利用機会が増えています。pluginが生まれ、特に後者はyarn*1で実行されるため既存のプラグインとも組み合わせやすく、JavaScriptと比較しても遜色ない状態と言えそうです。2019年3月時点で、Java特にMavenがどのようにsemantic-releaseを活用できるのか、まとめてみます。semantic-releaseとはプロジェクトにおいて以下の制約を導入することで、リリース作業をより一段階自動化する仕組みです。Messageだけと言えます。semantic-releaseは具体的なリリース作業を定義しません。このため使っているプロジェクト管理ツールやCIサービスを問わずに利用可能です。代わりに、リリース手順を構成するステップを定義しており、利用者はステップごとに必要な処理をフックできます。これは、Mavenがビルドライフサイクルを構成するフェーズを定義しているのと近いです。Maven自身が各フェーズにおける具体的な処理を定義せずプラグインに委ねているように、semantic-releaseも具体的なリリース作業の定義をプラグインに委ねています。Notifyするという運用もできそうです。出荷承認プロセスを持つコミュニティでも活用できるでしょう。Mavenとの併用semantic-releaseをMavenと併用する場合、semantic-releaseがMavenを実行する形になります。deployする形です。package.jsonは必須ではないですが、実際にはこのように作成してしまったほうがプロジェクトの見通しは良くなると思われます。これはpom.xmlをコミットするために@semantic-release/gitのカスタマイズが必要となるためです。devDependenciesにsemantic-releaseとそのプラグインが列記されるため、それらのバージョン管理がしやすくなる利点もあります。プロジェクトにpom.xmlとpackage.jsonが同居するので、CIツール側で設定ファイルの有無によるビルドツールの推定をしている場合は注意が必要かもしれません。高速なリリースが行えるのが大きな利点semantic-release最大の利点は、なんと言っても頻繁にリリースが行えることです。Cental等にデプロイを行うことができます。Deliveryが証明したように、高速かつ頻繁にユーザへ変更を届けることはプロジェクトの成功へダイレクトに効きます。導入可能なプロジェクトでは速やかに入れていくことが望ましいと思います。他には、semantic-releaseを利用することでリリースマネージャの手作業、例えばタグ打ちやCHANGELOG作成を自動化できる点も嬉しいです。Sourceとして利用する手法に切り替えることで、透明性と正確性を確保できます。Versionに従った形で決めるので、ユーザもバージョン更新の必要性と負担を簡単に見積ることができます。Repositoryの記憶容量が気になるかもしれませんが、メリットに比較して十分に安いコストではと感じます。OSS開発においてはここは特に気にならない問題でしょう。Messageをチームに普及するのが最初の難関かデメリットが小さいならJavaコミュニティにもすぐに普及するでしょうか?個人的には懐疑的です。大きく分けて2つの問題があります。Message自体、そこまでクリアに定義されているものではありません。Conventionsから生まれたもので、多様なプロジェクトに適合できるものにはまだなっていません。Messageに定義されていないコミット種別を利用することも禁止されていません。プロジェクトごとにコミット種別の亜種が生まれ、収集つかなくなる可能性がありそうです。fix(package)のすべてが使われています。1プロジェクト内でも統一されていないわけです。今のところ周辺ツールもあまり賢くないので、PRレビュー時にレビュアーがコミット種別を確認する必要があります。プロジェクト導入時の最初の難関は、不明瞭な定義をローカルルールに落とし込んできちんと普及させる、このプロセスにあるでしょう。Messageの利用を忘れたときに、コミットコメントの修正が面倒という問題があります。Gitはこれをサポートしていますが、コミット履歴の修正は基本的な操作と比べて難度が高いため、ある程度の慣れが必要です。Commitしてしまうという、若干粗い解決方法があります。Messageに準じたものにすればよいのです。PRタイトルはWeb画面から簡単に修正できるので、慣れていない人でも回しやすいでしょう。Messageとして不正な場合でもPRタイトルが問題なければパスしてくれます。以上で、Java屋がsemantic-releaseに思うことを見てきました。機能的には充分で、すぐにプロジェクトに適用することができます。nexus-staging-maven-pluginやmaven-release-pluginなどの既存設定をそのまま使えるので、新規プロジェクトのみならず既存プロジェクトへの導入も簡単でしょう。Javaコミュニティにおいてはさほど知名度がないため、コミュニティでの開発に浸透するのはまだ先だと思いますが、個人プロジェクトではぜひ使ってほしいです。ユーザが増え実績が積まれれば、Javaコミュニティにおいても利用が進むことでしょう。siteで作成できるサイトについて現時点での注意点をまとめる。skinについてmaven-fluido-skinが最も使われていてかつ実用的と思われる。以下の記述はこのskinのv1.7を利用することを前提とする。maven-site-pluginの設定方法Maven3から<reportPlugins>による設定が可能になっているが、最新の公式サイトでは非推奨になっているので利用を避ける。moment.Copyright情報の生成ページのフッターにCopyright情報が記載されるが、これはpom.xmlの<organization>と<inceptionYear>から情報を得て生成される。Holderが空になり違和感があるので、記入しておくと良い。Markdownの利用maven-site-pluginにdoxia-module-markdownに対する依存を追加すれば良い。.mdファイルはsrc/site/markdown以下に置く。SpaceのRequirementを明記することができる。これはmaven-plugin-pluginの機能で、<requirements>を利用して設定できる。他にも特殊なRequirementがあるなら<others>を使って明記することもできるようだ。昔から変わらないのでコピペで良い。Contributions(25日時点)でした。仕事でほぼ使ってないのにこの数字というのは、多いのでしょうか少ないのでしょうか。私は2018年にGitHubで927コントリビュートし、Findy内で1412位でした。(7月)、一日あたりの平均は2.6/日でした。2018SpotBugs周りの開発2018年もSpotBugsが一番活発な開発でした。commitsを超える貢献をしていました。commitsという感じで、Mavenプラグインを除けば最も活発なcontributorでした。commitsという感じでした。Probotはいろんな自動化が気軽にできそうで楽しいです。Sentryでサービスの監視をしていますが、Heroku上でChromeが起動しないことがあり、サービス自体はあまり安定させられていません。Doc側のAPIが整備されるのを待つ形です。今年でErrorproneプラグインもだいたい書けるようになり、これでPMD・Checkstyle・SpotBugs(FindBugs)・ErrorproneとJava周りの静的解析ツールはひととおりプラグインを実装できるようになりました。最近はJenkinsやMavenのプラグインに加えGradleのプラグインも学習中なので、ビルド周りの自由度はだいぶ上がった気がします。Reactorについては、Javadocky以外に使いみちを見いだせていないのが残念な感じです。Functionのような使いみちになるのでしょうが、そもそもサーバーレスではSpring自体ほぼ使わないという......。GraalVMでの起動高速化が一般的になれば別でしょうが、それまではJavaを利用しないという選択肢も有力だと個人的には考えています。来年の抱負SpotBugs本体は旧バージョンのメンテナンスを止めて新機能開発に注力できる予定なので、以前からやりたいと話しているマルチスレッド対応を盛り込めればと思っています。1年でできるとは正直思ってませんが、とりあえず依存関係を整理してスレッドアンセーフなクラスを特定することはできるでしょう。BCELに依存するほぼすべてのDetectorがダメだとは思いますが......。加えるなら、TypeScript・Kotlin・Rustといった言語の開拓でしょうか。基礎はもうあると思いますし、簡単なツールなら実装済みなのですが、もう少し複雑な事例も経験しておきたいところです。Probotを作成しました。github.comドキュメントがいつもどおり全部英語なので、日本語での解説をここに書いておきます。Docsが単体でPRレビュー用ビルドを提供していないので、レビューしてもらう時にステージングサイトやスクリーンショットを主導で用意しなければならない。Docs上でのビルドとホスティングを有効化し、アクセス用URLをPRに書き込む。Webhookと統合しておく。ユーザをメンテナーとして招待しておく。Docsプロジェクト名とその言語を指定する。GitHub上でrtd-botを有効化する。Docs側の設定項目(例えばドキュメントの場所など)には柔軟に追従できません。Docsにおける「メンテナーの招待」は、「全権限の委譲」にほかなりません。不安な場合はご自身でProbotをホストいただけます。Releaseを導入しました。思っていたよりも使いやすく、またDependabotがすでにcommitizen風コミットコメントに対応していたため、特に導入に障害はありませんでした。MavenやGradleでも使えたら良いんですが、そこはまだハックが必要そうです。DocsのAPIはまだ機能不足が目立ちます。v2でも認証機能すら無く、公開データへの読み取りアクセスしかできません。今回はこの問題の回避にPuppeteerを使っています。管理画面をNode.jsで操作しています。ダーティハックですが、利用規約上も問題ないはずです。Docsの画面はさほど大きく変更が入らないと思われます。直近の予定としては、i18nには対応したいと考えています。他にも対応必要な設定があればROADMAP.mdに追記のPRを送ってください。SonarQubeクラスメソッドさんのブログでSonarQubeの紹介がされています。そちらの記事では記事の半分ほどを割いてインストール方法を説明していますが、dockerを使えばより楽に行えますのでその方法を紹介します。dev.classmethod.jp検証用のSonarQubeを立ち上げる以下のコマンドで、組み込みデータベースを使用したサーバが立ち上がります。ユーザ名admin、パスワードadminでログインできます。このコマンドは英文公式ページからの引用です。sonarqubeなおalpineを使ったイメージもあるのですが、2018年8月1日現在でClassNotFoundErrorが出るなど不安定なようです。7.1-slpineなどのバージョンではなく、7.1などのバージョンの利用を推奨します。PostgreSQLを使ったSonarQubeを立ち上げる組み込みデータベースでの運用は検証用にのみ推奨されていますので、本番運用はRDBMSの利用が必要です。upすればSonarQubeとPostgreSQLが立ち上がります。GitHubプラグインのインストールを自動化する$SONARQUBE_HOME/extensions/pluginsディレクトリにプラグインの.jarファイルを保存することで、プラグインをインストールし有効化できます。英語での情報発信をはじめました。宜しければそちらもご購読を。