travis-ci今年はビルド周りで自分の常識がいろいろ変わった年だったので、既存の知見もあわせてまとめます。CIは不定期にビルド用仮想マシンを更新しますが、そのタイミングでの最新のMavenを仮想マシンに入れるようです。このブログ投稿時だと3.5.2が入っています。Wrapperを使うと良いでしょう。CIはプロジェクトルートディレクトリにmvnwスクリプトがある場合はそれを優先的に使います。オプションを忘れないようにします。このオプションによってMavenはインタラクティブなログを抑制するようになり、ログサイズが激減します。CIはログサイズに上限があるため、うっかり忘れるとビルドが不安定になります。現状これらのファイルはコメントを書けないので、チームで使用する場合はどこかで説明が必要でしょう。3.3.1SonarCloudによるコード解析FOSSならSonarCloudを使えば無料で解析できます。CIには専用Addonがあって、MavenでSonarQube専用プロパティをややこしく設定しなくても、pom.xmlをよしなに解析してプロジェクトホームやIssueトラッカのURLを見つけてくれます。GitHubなおコード解析をPRにも働かせる場合は、PRのもととなるブランチも同じリポジトリに存在する必要があります。これはトークンの復号化に必要なためです。Nexusへのデプロイこれを取り入れるかどうかは意見が別れるところだと思います。Nexusのパスワードをリポジトリにコミットする必要があるのです。Pluginを使うようにしています。SpotBugsのような共同リポジトリの場合、リリース難度を下げ属人性をなくすために使用しています。settings.xmlを暗号化してリポジトリにコミットし、それをデプロイ時に使うだけです。以下のPRが参考になると思います。GitHubGPGのkeyringは以下のようにコマンドで出力できます。リリースの属人性をなくすため、リリース手順書も合わせてコミットしておくと良いでしょう。settings.xmlのテンプレートもあると、引継や暗号化済みファイルの更新に役立ちます。Contributorに対するリマインドGitHubはPRやIssueにテンプレートを作成することができます。Guidelineを作成することもできます。従来はこれがユーザに対するほぼ唯一のIssue/PR作成時のリマインダでした。チェックボックスをテンプレートに入れたとしても、すべてのContributorがこれを使ってくれるわけではありません。個人的には以下のブログで紹介されているProbotに期待しています。