3．QAチームのチェックでOKになったので、アプリをリリースしたい
QAチームからOKが出たら、あとはエンジニア側でリリース作業に入ります。
具体的なリリース作業は
- リリース用のアプリをビルドする
- ビルドしたバイナリをストアにアップロードする
- リリースノートなど、リリースに必要な情報を入力する
- アプリをリリースする（iOSの場合は審査提出）
となります。
以前は、この作業のうちリリース用のアプリをビルドする手順を、社内にあるマシン内のJenkins上で行っていました。ただ、社内ネットワーク内にあるために外部サービスとのWebhookでの連携が難しいことや、各アプリのiOS版のSwiftバージョンを上げていく際に、マシン内に複数バージョンのXcodeを置いて切り替える必要があり、そのあたりの運用が非常に手間だったのをきっかけに、Bitriseに移行しました。
Bitrise移行後、リリース時は以下の流れになっています。
- Slack上でbotに「リリースするぞ」と言う
- botがGitHub API経由でバージョン別のブランチにタグを作成する
- タグ作成をフックにして、Bitrise上でリリース用のビルドが走る
- リリース用のビルドが完了すると、Bitriseから各ストアにバイナリがアップロードされる
- 手動でリリース内容を設定し、申請 or リリース版を公開する
こちらの流れの中で使ってるbotも、先ほどと同じbotを使っています。
やりとりはこんな感じです。
リリース内容だけ手動ですが、これは現状ユーザーに分かりやすいリリース内容の自動生成が難しいため、今のところ自動化していません。
4．現在QAチームに見てもらっているが、前のバージョンに不具合があって、その修正を先に出したい
こちらはちょっとイレギュラーなケースになります。例えば大きな機能のリリースが続くようなケースだと、
- バージョン1.0.0をリリースした
- 次のバージョン1.1.0をリリースしたいのでQA中
- その間に、1.0.0で不具合が見つかったので、1.1.0より先にbugfix版の1.0.1を出したい
といった状況になるケースは少なくないと思います。
以前の運用では正直このようなケースの対応は難しく、結局「次のバージョンにbugfixの修正も入れて、早くリリースまで持っていく」といった運用になっていました。
現在の運用だとリリースフローの中で、リリースしたタイミングでgitにタグを作成することが自動的に組み込まれているため、1.0.0がどのコミットからバイナリを作られているのかが正確に分かります。つまり、そのタグから1.0.1というブランチを作成することで、bugfixだけをそのブランチにcommitして修正版を出すといったことが可能になりました。
この場合、1.1.0は既にmasterから切り離されているので、1.0.1に追加したhotfixと同じ修正を1.1.0に入れないとデグレードになってしまいます。そこだけ注意が必要です。
さいごに
今回は、モバイルチームがリリース周りの運用で抱えていた問題と、それをどう解決したのか、事例を紹介しました。
運用周りの改善は、なかなか面倒になって後回しになりがちです。しかし、改善することによって本業の開発に集中できるようになります。今回紹介したようなケースで困っている方の参考になれば幸いです。
