はじめに

PhotoructionでiOS テックリードをしている數田です。

今回は私が加入してからのiOSチームの運用ルールの変遷の一部を振り返ります。

チームで開発するの運用ルールが定まっていなかったので、チームを運営する際の参考になる箇所もあるかと思います。

運用ルールで手動で行うことを増やすと漏れが発生するので、基本的に自動化できることしか取り入れていません。

運用ルールの変遷

ビルドが失敗する

一般的にはビルドが通る状態でPull Request(以下 PR)が作成されますが、ブランチをチェックアウトして手元でビルドすると失敗することが、多々ありました。

PRをレビューする都度、手元でビルドの確認するのはプログラマーの三大美徳に反します。

Bitriseを導入しPRのチェックが通っているものレビューしてマージする運用に変更しました。

マージタイミングがわからない

複数人で開発しているとPull Requestが多数作成され、すぐにレビューしてマージしたい衝動に駆られます。リリースタイミングが異なるPRも出てきて、間違ってマージしてしまう問題が発生してしまいます。

PRにリリース時期の記載がなかったため、確認に時間を取られていました。リリース時期を

PRのタイトルや説明に記載する方法が最初に思いつきますが、以下のような記述の揺らぎが発生します。

2022年1月リリース
2022年1月31日リリース
バージョン x.y.z

記述の揺らぎが発生せずGithub のマイルストーンを設定することにしました。マイルストーンで絞り込めるようになり、優先的にレビュー、マージするPRがわかりやすくなります。

手動でマイルストーンを設定する運用を行っていると設定漏れが起きます。Dangerでマイルストーンが設定されているかのチェックを追加します。

PRの種類による絞り込み

PRのレビューする際に機能改修やバグフィックス、ライブラリのアップデートなど変更の種類によってレビューの観点が異なります。

開発用ライブラリのアップデートのPRなどすぐにマージしても問題ないものを一覧からタイトルのみで探さないといけないので多少手間がかかります。

PRの種類で絞り込めると手間が減るのでPRの種類の情報を付与する方法を検討した結果、ブランチ名で判別できそうなので、プレフィックスによってラベルをつけるGithub Action PR Labelerを追加しました。

現在iOSのプロジェクトでは以下の種類のラベルをつけて運用しています。

Feature: ['feature/*']
refactor: ['refactor/*']
Issue: ['issue/*']
bug: ['fix/*', 'bugs/*']
cre: ['bugs/*']

バグ解消

バグ解消のためCREチームがあり、PRはQAチームでテスト完了後にマージする運用となっています。CREが担当したPRは cre のラベルが付与されているの絞り込みできますが、テストが完了する前にマージしてしまうと、不具合が発生する可能性があるので、マージ前にテストの状況を把握する必要が出てきます。

PRにテストの状況を付与する方法を検討して、Github projectsでテストの状況をトレースすることで解決しました。