REALITY iOSアプリの開発とリリースされるまでの流れ

WWDCで発表された async/await が iOS15 以降でしか使えないことにショックを受けて寝込んでしまったiOSエンジニアのションローです。

Swift Concurrencyについては Xcode 13 Beta Release Notes 内に Known Issues として記載されているので、もしかしたら後々対応バージョンが広がるかも！？と期待しています。

この記事について

弊社ではソフトウェアエンジニアの方を随時募集中なのですが、採用活動の中で「開発フローや雰囲気ってどういう感じなんですか？」という質問を頂くことが多かったので、まとめて記事化しちゃおうと思った次第です。

自分がiOSチーム所属の為その立場からの視点になりますが、他チームも大体同じような感じなのでiOSエンジニアでない人でも参考になるはずです。

ソフトウェアエンジニアの開発タスク管理

開発タスクは GitHub Enterprise 上の Issue として管理されています。
なので、自分のタスクを知りたかったら基本的には Issues を見ればOKです。

タスクのアサインについて

アサインについては、PM（プロダクトマネージャー）から依頼される開発・修正とそれ以外（開発環境の改善やリファクタリング、品質改善のためのプロジェクト等）で大体の工数割合を決めて都度アサインされる形になります。
品質改善のプロジェクトがどんな感じなのかについては、過去にソフトウェアエンジニアの漫喫が記事を書いているのでそちらを御覧ください。

アサイン~PR（プルリクエスト）のレビューの依頼

アサイン以降は前述の通りIssueベースですすめることになり、多くの場合は実装がある程度落ち着いたタイミングでPRを上げます。
ただし、設計に不安がある場合はDraftとして早めにPRを上げて事前レビューを依頼することもあります。

レビューの依頼は review_request ラベルを付与することで行います。
ラベルが付与されたタイミングでbotがレビュアーのアサインとSlack上での通知をしてくれます。

ちなみにiOSチームでは「2人からのApproveでマージOK」というルールで運用しています。

自身の開発タスクに集中してしまい依頼されたレビューを忘れてしまうことがあったので、対策としてレビュアーに対してbotからレビュー状況の通知を毎日投げることで、botからレビューしてくれ圧がかかるようになっています。

申請・リリースフローの話

iOSアプリの申請・リリースの運用は以下です
・木曜日の夕方にコードフリーズする
・金曜日にリリースノートを更新し、審査に提出する
・月曜日の昼にリリースする

リリースノートの作成はPMのリリース担当大臣が行っており、申請に含まれる変更内容はbotからリリース担当大臣に自動で通知が行くようになっています。

リリースノートの更新後、ストアへの申請Jobをソフトウェアエンジニアが手動で実行しています。

申請処理を行うジョブはmasterブランチに新たなコミットがプッシュされた際に実行されるようになっています。

masterブランチへのPRはgit-pr-releaseを利用してbotが作成してくれるので、申請作業担当者は変更内容を確認した後にマージボタンを押すことで申請作業が完了します。
ちなみに申請作業はiOSエンジニアの中でローテーションしながら担当しています。

無事に審査が完了し、バグも発見されなければ月曜の昼にリリース担当大臣が手動でリリースを行って完了です。開発お疲れさまでした！

まとめ

RAELITY iOSアプリの「開発からリリースまでの流れ」についてざっくりまとめてみました。
申請やリリースフローはまだルールの更新・自動化で効率化する余地があるので、今後も改善に取り組んでいきたいと思っています。

この辺の開発効率改善を一緒に勧めてくれるエンジニアの方も随時募集中ですので、ご興味ある方はぜひご応募いただけると幸いです！