保育園のおゆうぎ会を見て、我が子の成長ぶりに不覚にもほろっときて歳取ったなと実感している中村です。こんにちは。
今日は、一般に利用できるライブラリをGithubなどで外部に公開しつつ、内部のビジネスに関わるところは非公開リポジトリで開発を進めているようなケースでの、Backlogの事例を紹介します。
Backlog APIに関連する3つのプロジェクト
Backlogでは、数ヶ月ほど前からBacklog APIバージョン2とそのJavaラッパーライブラリであるBacklog4J v2を提供開始しました。内部では、Backlog4Jを用いて記述した、APIバージョン2の結合テストを用意しています。これらの関連を図に表すと、下記のようになります。
- apiプロジェクトはgit push後、自動的に社内ステージングサーバにデプロイされる
- Backlog4JはGitHub上で公開されており、artifact（Jarファイル）がMavenリポジトリ上で管理されている
- api testプロジェクトでは、最新のBacklog4Jを用いてステージングサーバに対してテストを行う
Backlog4Jは外部のユーザに利用してもらうため、Github上で公開しています。ライブラリ自体は外部に公開しつつ、その他の非公開のコードとどう連携してテストを行うか、が今回のポイントとなるところです。
それでは、下記の2パターンの開発フローを、以下で説明していきます。
- API側を修正したとき
- Backlog4J側を修正したとき
apiを修正したとき ~ステージングサーバへ自動デプロイ~
apiプロジェクトのコードを修正したときは、以下のようなフローになります。
- 開発者がapiプロジェクトにgit push
- push後のweb hookで、社内Jenkinsに対して通知
- Jenkinsがapiプロジェクトのユニットテストを実行
- ステージングサーバにapiをデプロイ
- ステージングサーバに対して、api testプロジェクトでテスト実行
社内では、CIサーバにみんなだいすきJenkinsを使っています。ステージングサーバへの自動デプロイと、それに対して自動テストするという、割とよくある構成ですね。
Backlog4Jを修正したとき ~TravisからJenkinsへ通知~
一方、ライブラリ側のBacklog4Jを修正したときのフローは、以下のようになっています。
- 開発者がBacklog4Jにgit push
- push後のweb hookで、Travisに対して通知
- TravisがBacklog4Jのユニットテストを実行
- Backlog4Jをパッケージングして、JarファイルをMavenリポジトリにデプロイ
- 社内Jenkinsに通知
- ステージングサーバに対して、api testプロジェクトでテスト実行（そのとき、Mavenリポジトリから最新のBacklog4Jを取得する）
Travisでのテストはユニットテストレベルで、主に内部的なロジック部分のテストを行っています。ここでは通信が発生するようなテストは行っていません。実際のサーバと通信するようなテストは、社内Jenkins上のapi testというプロジェクトが受け持っています。
このとき、Travisでのテストを無しにして、全てJenkins上に集約するというのも一つの選択肢です。ですが、Travisでテストしてそのテスト結果もBacklog4Jの利用者に確認できるようにしておくほうが、ライブラリ利用者にとっても安心できるかと考え、このように2段階でテストを行うようにしています。ほら、こういうバッジですね。
Travis-Jenkins連携時の認証情報の取り扱い
Backlog4J修正時のフロー中では、以下の認証情報を必要とします。
- (4) : Mavenリポジトリにデプロイする際のユーザ / パスワード
- (5) : 社内Jenkinsに通知する際のユーザ / パスワード
Travisの設定は、travis.ymlというファイルに記載してコミットしておく必要があります。ですが、単純に上記の認証情報をtravis.ymlに記載しておくと、（private設定をしていないプロジェクトの場合は）誰からも認証情報を参照されてしまいます。
こういった場合、各認証情報を環境変数に設定して、Travis起動時に外部から与えてやることにしましょう。公式ドキュメントにあるように、Travisでは設定画面から環境変数をセットすることができます。
（なお、設定画面から設定する以外の方法として、travis.ymlに暗号化した形で認証情報を記載するやり方もあります。ただ、環境変数のキーも一緒に暗号化されるために、どんなキーが定義されているかが分かりづらくなるため、今回は設定画面から定義する方法を選択しました）
Gradleの設定ファイルと連携するために”ORG_GRADLE_PROJECT_”というプレフィックスを付けていますが、設定している項目は一見で判断できると思います。
今回は、自社プロダクトとその公開ライブラリがある場合のテストの扱いについて、Backlog APIバージョン2での事例を紹介しました。
ヌーラボでは、このような自動化に興味があるエンジニアを募集しています。興味がある方は、ぜひこちらの採用情報のページからご応募ください！
カバーイメージ : Test (138/365) by Andy Rennie