SHOWROOM iOS CI/CD周りのお話
こんにちは。SHOWROOM iOSエンジニアの郭(@huiping192)です。 今回はSHOWROOM iOS CI/CD 周りを紹介したいと思います。
CI/CD環境
Bitrise + fastlane + deploygate + Slack bot
Bitrise
Bitrise採用の理由はXcodeバージョン更新の速さです。
今回のiOS13対応もXcode 11 beta早いタイミングでBitriseが対応し、
おかげでiOS13向けての開発CI止めることなく開発できました。
fastlane
iOSチームでは万が一、CIサービスが使えない状況になったとしても、リリース業務に支障が出ないよう、fastlaneに集約しています。
また、他のCIサービス移行も楽にできちゃいます。
DeployGate
iOSチームは元々、TestFailryを使っていましたが、AndroidチームはDeployGateを利用しており、ツールが別れていました。 我々はツールをDeployGateに統一することにしました。
Bitrise Workflow運用
Workflow Trigger
Pull Request
- Pull Request が作られた際、まずはCIを動かし、buildとテストを走らせます
Push
- masterにmergeされた際、自動的にsubmitされます
- release/* にpull reqeustがmergeされた際、自動的にInHouse buildを作り、slackでプロダクトテストチームへ連絡してくれます
Workflow
Test(dev-fastlane)
Pull Request作ると自動的にこのworkflowを走らせ、buildとunit testを実行します。 ほかのworkflowと違うのは Dangerによる事前コードチェックとgithubのPull Request状態の更新です。
Danger
SHOWROOM iOSチームではほかのメンバーがreview入る前にDangerのswiftlintによるチェックが入って、 LGTMもらったらメンバーがcode reviewに入る感じになります。
通ったらこんな図です。笑
InHouse build (inhouse-fastlane)
iOSメンバーシップは年100端末しか登録されない＋都度都度の端末登録も面倒なので、SHOWROOMではエンタープライズ版を使ってプロダクトテストチームに渡し、テストしてもらっています。
DeployGate上げたらプロダクトチームに通知。
adHoc build (iap-fastlane)
大体の場合はInHouse buildでテストできますが、InHouse buildは課金のサンドボックステストできないため、adHoc buildを作ってプロダクトチームに課金周りをテストしてもらう場合があります。
ですが、inhouseのworkflowほぼ同じです。
App Store submit (release-fastlane)
master branchがPull Requestされたら自動的にsubmitにフォローが入るようにしています。
submit成功後はslackに通知してくれます。
Bitrise側はfastlaneのscriptを呼ぶだけ、fastlane内部ではsubmit前チェック、本番build作成、metaデータ更新、tagきりなどを行っています。
Slack Bot
プロダクトテストはほぼInHouseで検証していますが、エンタープライズbuildだと課金検証できないため、adHoc build作る必要があります。
Slack Bot作る前には毎回iOSエンジニアに頼んで作るしかなかったのですが、Slack Bot作ることで、エンジニアの作業が必要なくなりました。
最後
SHOWROOMでは絶賛iOSエンジニア募集中なので、CI/CD、自動化周り興味ある方も大歓迎です！
お待ちしております。
