こんにちは。第4事業部の原です。
現在、新人研修の講師として、新人からの質問対応やレビューを行っております。
前年度までの課題として、成果物であるプロジェクトの仕様を確認するのに
逐一gitからソースコードをpullして手動で動作確認をしなければならず、
少し負担となっておりました。
自動で成果物プロジェクトの動作を確認することで講師の生産性を上げることを目指して、自動RVシステムを構築しました。
これにより、成果物の動作確認が自動でできます。ただし、ソースコードがコーディング規約に沿っているかは講師が目視で確認する必要があります。
これまでの研修生成果物の講師レビュー内容が
動作確認+ソースコード確認
だったのが、
ソースコード確認のみになります。
構築材料
以下のサービスやプログラムを駆使して構築しています
・Jenkins
・Gradle
・Redmine
・GitBucket
・Slack
概要図
自動RVの流れ
研修生がソースコードを提出(git pushコマンド・手動)
↓
GitBucketがリポジトリへのプッシュを検知して、JenkinsへHTTPリクエストを送信する(自動)
↓
HTTPリクエストをJenkinsで受信したら、ソースコードチェックジョブを実行する(自動)
↓
ソースコードチェックジョブの中で、JUnitのテストコードをGradleで実行する(gradle testコマンド・自動)
↓
Jenkinsのジョブ実行結果をRedmineのチケット内容へ反映させる(自動)
↓
RedmineのチケットをRedmineAPIを使用して作成する(自動)
↓
Redmineチケットが作成されたことをSlackが通知する(自動)
↓
研修生がRedmineのチケットの内容を確認する(手動)
という流れになっています。
設定と実装に関して
GitBucketのWebhook設定とJenkinsのビルドトリガの連動、Jenkinsジョブの中にあるShellでRedmine APIを使用することで実現しました。
・Webアプリのデプロイ
・コミットメッセージの確認
・JUnitのテスト実行
・Redmineのチケット作成
はShellで実装しました。
運用した結果
実際に新人研修で運用してみたところ、
・Java単体のテスト
→ソースコード単体を実行するため、テスト自体は問題なし、CheckStyleのエラーの存在は教えてくれるものの原因が不明
・Tomcatを使用するWebアプリのテスト
→テストが成功したり、しなかったり...
→jspのタグが違うだけで自動RVがNG、CheckStyleのエラーの存在は教えてくれるものの原因が不明
研修対応でも自動RVに関する問い合わせが多くなり、使用者にとって不明な部分は、運用でカバーする結果となりました。
こういった事象は懸案事項として次年度の研修で使用するにあたり、修正していきます。
所感
最初はJenkins？Gradle？何それ状態でした。
しかし、簡単な処理を実装していくにつれて、今の自動RVシステムが実現できました。
設計から運用まで携わり、貴重な経験になりました。
新しいシステムを導入することは、他の人にも使ってもらえるように働き掛けないといけないので、大変でした。
今年度の運用の経験をもとに、次年度からは自動RVシステムを使用する方にもわかりやすいシステムづくりを心掛けたいと思います。
