Android 版 feather 開発担当の @numa08 です。
現在ベータ版の feather ですが、ベータ版配布の仕組みが整ってきたので記事にまとめようと思います。
GitHub のイベントを契機に CI ツールにデプロイをさせる
[caption id="attachment_657" align="alignnone" width="264"]
developブランチへのpull requestをトリガーにビルドが行われるので、developブランチは常に正しいソースコードが管理される[/caption]
feather の開発には、GitHub と Pull Request そして、 CI ツールとして Jenkins が積極的に利用されています。CI ツールの利用方法としてビルドやテストがよく挙げらます。実際 feather でも Pull Request の作成や、特定のブランチの変更をトリガーにしたビルド、テストが実行されているのですが、最近は CI ツールにデプロイ作業を担当させる事も増えてきました。
コベリンでも feather の開発で、 Pull Request のマージをトリガーに Jenkins がデプロイ、つまりベータ版のテスターへの配布を行う仕組みが整っています。
Pull Request をトリガーにしたデプロイ
[caption id="attachment_658" align="alignnone" width="300"]
developからbeta-releaseへpull-requestのマージをビルドすることで、デプロイ作業の可視化ができる[/caption]
デプロイの対象となるブランチは、現在beta-releaseという名前のブランチが設定されています。 Jenkins はこのブランチをビルドしテストした後にfabricへのバイナリのアップロードに加えて、 Git のタグの作成、 GitHub の Release ページの作成を行います。
そして、開発者はデプロイを行う際にローカルな環境で beta-release を変更するのではなく、 develop から beta-release に対して Pull Request を作ります。こうすることで、
- 前回のデプロイと今回のデプロイでどういった機能変更、追加が行われたのかをWebページ上で確認しやすくなる
- Pull Request の中でデプロイに関する最終確認を行うことができる。Pull Request をマージすればデプロイされるし、キャンセルすればされない
といったメリットがあります。
[caption id="attachment_659" align="alignnone" width="300"]
pull-requestを作ることで、前回のデプロイとの差分などが見やすい[/caption]
ただし、現在 feather においては完全に Pull Request をトリガーにベータ版がテスターに配布されるわけではなく、配布を行う最後の作業は手動で行っています。これは、ベータ版の配布の前にメールを送っていること、ベータ版の配布を夕方5時くらいとしているためです。
将来的に feather を Google Play Store へアップロードするフローを作る際には、 Pull Request をトリガーにした完全に自動的なデプロイを行うと思います。
まとめ
Jenkins を始めとした CI ツール、サービスはビルドやテストだけではなくデプロイを行うことも現在では標準的な機能です。 Pull Request をトリガーにデプロイを行うことで、デプロイ内容の確認・共有などのメリットが得られることも分かっています。
良い感じにツールやサービスを組み合わせて、複雑なフローやタスクを簡略化することを積極的に行って行きたいものです。
