iOSアプリの週次リリースを支える技術

iOS チームの荒巻です。SmartNews アプリは日米でユーザーが急成長し、チームも急激に拡大しています。そのような状況の中で昨年、SmartNews アプリの Weekly リリースを支える技術というイベントを開催しました。 イベントでは主に組織体制やコミュニケーションについて説明しましたが、ここでは技術的な側面を紹介したいと思います。主に iOS チームの取り組みを紹介しますが、Android チームもおおむね同じような仕組みで回っています。 背景と全体のプロセスの理解のため、まず開発サイクルとフェーズについて、次に各フェーズで起点となるタイミングについて説明します。 そのあと毎週のリリースを実現するための開発フローや GitHub ワークフローなどについて紹介します。 開発サイクルの過去と現状について説明します。 2017 年時点では、毎週 iOS 版と Android 版を交互にリリースしていました。つまり iOS 版だけを見ると二週間に一度リリースする状況でした。 2/27-3/5 3/6-3/12 3/13-3/19 3/20-3/26 この体制はおおむねうまく稼働していましたが、リリースのためには毎回様々な手作業や確認を行う必要があり、それなりに時間を取られていました。 一方 PdM(Product Manager) の視点では、 同じ機能を両方のプラットフォームにリリースするのに余分に一週間かかる 機能をリリースするタイミングを逃すと追加で二週間待つ必要がある という課題がありました。二週間待ちたくないため、スケジュールを数日延長することもしばしばありました。 リリースサイクル短縮プロジェクト これらを解決するため、リリースサイクルの短縮をプロジェクト化し、以下のような方針で少しずつ改善していきました。 全ての手順をドキュメント化・定型化・チェックリスト化 自動化できる単純作業はできるだけ自動化し、結果を Slack に通知 全体のプロセスを開発者だけでなく PdM や QA チームへも周知 その結果、以下のような工夫を取り入れることになりました。 Google Sheets をスケジュールのマスターとし、Google Calendar と Notion に連携 機能追加するときは Notion の表に機能を追加し、対象バージョンを指定する ブランチ戦略の変更、自動ブランチ生成、自動マージ支援 Xcode Server でビルド、テスト、TestFlight および Firebase へアップロード GitHub Actions でリリース それぞれのチェックポイントで Slack に通知 それぞれについて、後半で説明していきます。 2021 年 5 月現在、毎週リリースを行なっています。継続的にリリースサイクルを短縮する取り組みを続け、2020 年にこの体制に到達しました。 大まかなフェーズは プランニング -> 開発 -> QA -> リリース の 4 つで、毎週それぞれのフェーズがパイプライン状に処理されていきます。例えば 2/26 の週にはバージョン 8.30.0 をリリースしますが、同じ週に QA チームは iOS 版と Android 版の 8.31.0 に対して QA(品質保証)を行い、開発チームは 8.32.0 の開発に取り組みます。8.33.0 のプランニング確認も行います。 2/26-3/4 3/5-3/11 3/12-3/18 3/19-3/25 各フェーズの起点となるタイミングについて説明します。 上の表の「プランニング」の週に行います。リリースの3週間前にプランニング確認のミーティングを行います。開発の進捗や、一週間で QA が行える分量なのかなどを確認して、そのバージョンに含める機能を最終調整して確定します。そのタイミングまでは、PdM やエンジニアが Notion に機能を追記していきます。 上の表の「開発」の週に行います。リリースの2週間前に QA 準備のミーティングを行い、そのバージョンのテストシナリオや QA リソースが足りているかどうかを確認します。休日などの都合に応じて工程調整を行ったりもします。 上の表の「QA」の週です。QA 開始前までに全ての pull request をマージしておく必要があります。このタイミングに間に合わなかった場合は次のバージョンに延期されます。QA 開始の前日の夜に trunk からリリースブランチを生成します。現在の QA 開始は金曜日であり、木曜日の夜にリリースブランチを生成しています。 ちなみに以前は月曜日から金曜日まで QA を行なっていましたが、最終確認が延びると週をまたいでしまうので、木曜日に変更しました。(実は上の表も一週間が金曜日からはじまっています) 通常、上の表の「QA」の週の最終営業日です。QA が完了すると、QA チームのマネージャーが Slack に完了報告します。それをもってリリース担当者がリリース版の準備に入ります。 ここからは開発支援のスクリプトや自動化について紹介します。 リリース担当者を持ち回りで決め、チェックリストを Notion のテンプレートにより作成します。 リリースのためのチェックリストは以下のような内容で 20 項目ほどあります。リリースしたあと、次の担当者に引き継ぐところまでが一連の手順となります。(※ なお実際に運用しているものは英語です) リリースの日付に関するマスターデータは Google Sheets で管理するようにしました。QA 開始やリリースの日付を入れておき、GitHub Actions ワークフローの cron タスクにより、Notion などに同期します。(例えば Notion に ios 8.30.0 (2021-03-01 リリース予定) バージョンに対応する milestone の生成 GitHub Actions ワークフローの cron タスクです。リリースのマスターデータを拾ってきて、各バージョンに対応する milestone(たとえば 1.0.0 日付をスクリプトで前処理し、作成する必要があれば、GitHub API で milestone を登録・更新します。(以下は新規登録の一部) - name: create milestones by calling github API env: CREATES: ${{ steps.filter.outputs.creates }} run: | echo $CREATES | jq -c '.[]' | while read release; do echo $release curl --request POST \ --url https://api.github.com/repos/${{ github.repository }}/milestones \ --header 'Authorization: Bearer ${{ secrets.GITHUB_ACCESS_TOKEN }}' \ --header 'Content-Type: application/json' \ --data "$release" done GitHub Actions ワークフローの cron タスクです。QA 開始の前日の夜に trunk からリリースブランチを生成して push します。また、GitHub 上に、そのバージョンに対応したリリース用の issue(たとえば Release 1.0.0 - name: bump version env: GITHUB_ACCESS_TOKEN: ${{ secrets.GITHUB_ACCESS_TOKEN }} VERSION: ${{ steps.next_version.outputs.version }} run: | file_name=App/SmartNewsApp.xcconfig git checkout develop sed -i -e "s/APP_VERSION=.*/APP_VERSION=$VERSION/g" $file_name - name: create pull request uses: peter-evans/create-pull-request@v3 with: token: ${{ secrets.GITHUB_ACCESS_TOKEN }} commit-message: Bump version to ${{ steps.next_version.outputs.version }} branch: feature/bump-version-to-${{ steps.next_version.outputs.version }} base: develop GitHub Actions ワークフローの cron タスクです。リリースする機能は全て QA 開始の前日までにマージする必要があるため、その前日 (つまり QA 開始の前々日) に、該当するバージョンのマージされていない pull request を Slack に通知するようにしました。(以下に一部抜粋) - name: create milestones by calling github API env: CREATES: ${{ steps.filter.outputs.creates }} run: | echo $CREATES | jq -c '.[]' | while read release; do echo $release curl --request POST \ --url https://api.github.com/repos/${{ github.repository }}/milestones \ --header 'Authorization: Bearer ${{ secrets.GITHUB_ACCESS_TOKEN }}' \ --header 'Content-Type: application/json' \ --data "$release" done GitHub Actions ワークフローの cron タスクです。QA 開始の前日の夜に trunk からリリースブランチを生成して push します。また、GitHub 上に、そのバージョンに対応したリリース用の issue(たとえば Release 1.0.0 - name: bump version env: GITHUB_ACCESS_TOKEN: ${{ secrets.GITHUB_ACCESS_TOKEN }} VERSION: ${{ steps.next_version.outputs.version }} run: | file_name=App/SmartNewsApp.xcconfig git checkout develop sed -i -e "s/APP_VERSION=.*/APP_VERSION=$VERSION/g" $file_name - name: create pull request uses: peter-evans/create-pull-request@v3 with: token: ${{ secrets.GITHUB_ACCESS_TOKEN }} commit-message: Bump version to ${{ steps.next_version.outputs.version }} branch: feature/bump-version-to-${{ steps.next_version.outputs.version }} base: develop GitHub Actions ワークフローの cron タスクです。リリースする機能は全て QA 開始の前日までにマージする必要があるため、その前日 (つまり QA 開始の前々日) に、該当するバージョンのマージされていない pull request を Slack に通知するようにしました。(以下に一部抜粋) message = """ こんにちは、以下のフィルターは、修正バージョンが現在のバージョンに設定されており、まだクローズされていないチケットを表示します。ご自身に割り当てられたチケットを確認し、次のバージョンへ進めてもよいかどうかお知らせください。よろしくお願いいたします。 https://jira/issues/?jql=%20status%20NOT%20IN%20(Closed%2C%20Resolved)%20and%20fixVersion%20%3D%20{version} """.format(version=os.getenv("NEXT_RELEASE_VERSION")) slack_client.chat_postMessage(channel=os.environ['SLACK_CHANNEL'], thread_ts=thread['ts'], text=message) QA が完了したら、リリース担当者がリリース用の issue をクローズします。それによりリリース用の GitHub Actions ワークフローが発動し、master ブランチに対して以下の処理が実行されます。 - App Store 用のバイナリをビルドする - GitHub にバージョンのタグを打つ - TestFlight に ipa をアップロードする - TestFlight の処理が完了するまで待つ (ポーリング) - dSYM をダウンロードして、Firebase Crashlytics にアップロードする - 各言語の What's New セクションの内容を App Store に転記する - App Store Connect 上で Submit GitHub 上のリリースですが、バージョンのタグを打ったとき、GitHub Actions ワークフローにより作成しています。CocoaPods を導入しており、Pods/ディレクトリはリポジトリに含めていないのですが、リリースには Pods/以下のソースコードも含めるようにしました。(こちらについては Qiita にて「GitHub Actions でリリースする」という記事を書きました。) また、App Store Connect の申請状況を監視しており、審査状態が更新されると Slack に通知されます。 リリースブランチへの自動 cherry-pick 以前は git-flow 風の開発フローを取り入れており、リリースブランチを master ブランチから分岐させていました。しかし、毎週リリースに適応するため、TBD (Trunk Based Development) に乗り換えることにしました。TBD では基本的に trunk に対して開発を行い、不具合修正も trunk に対して行います。リリースブランチへの修正が必要なときはリリースブランチに対して cherry-pick します。これにより最終成果物を trunk へバックマージする必要がなくなりました。 そして多くの場合、このcherry-pickは単純にリリースブランチにそのまま取り込むだけなので、GitHub Actionsワークフローで自動化することにしました。pull requestに適切なマイルストーンを設定し、need cherry-pickのラベルを設定しておきます。このpull requestをマージすると、GitHub Actionsワークフローが発動し、リリースブランチにcherry-pickするpull requestを作成してマージします。ただコンフリクトすることもあり、その場合はSlackに通知されるので、開発者が手動でコンフリクトを解決してpull requestを作成します。 cherry-pickの処理はPythonで書かれています。(以下に一部抜粋) for commit in pr.get_commits(): print(f"Cherry-picking: {commit.sha}") try: print(gitrepo.git.cherry_pick("-x", commit.sha)) except Exception as e: print(e) print(gitrepo.git.diff()) slacksender.send(slack_webhook, repo_name, pr.user.login, pr_number, version, commit.sha) exit(0) print("Pushing branch:", cherrypick_branch) print(gitrepo.git.push("origin", cherrypick_branch)) pull requestのレビューには以下の二つの課題がありました。 総数が多く、すぐにレビューされないことがある 情報共有やワークロードの観点で全員にレビューの機会を持ってほしいが、レビュアーが偏ったり、誰もレビューしないまま数日が過ぎてしまうことがあった。 特定のコンポーネントはドメイン知識が必要 現在、開発部門はマトリックス組織となっており、複数のグループにわかれて開発を行っている。リポジトリは一つで、共通部分はありつつも、特定のコンポーネントはドメイン知識が必要な状態となっている。 これを解決するため、Auto Assign Actionを導入し、優先的にレビューする人をランダムに二人割り当てるようにしました。(もちろん割り当てられなかった人もレビューしてよい) また、コンポーネントをラベルとして用意しておき、コンポーネントのラベルを指定したときは、一人はコンポーネントのオーナーのチームから選ぶように拡張しました。例えばAdsというラベルを指定すると、一人は広告チームから選ばれます。 プロジェクトファイルのコンフリクト Xcode環境ではプロジェクトファイル(.pbxproj)が競合しやすいです。(以下に一部抜粋) objectVersion-47 #!/usr/bin/env ruby require 'xcodeproj' Xcodeproj::Project.open('MyProject.xcodeproj').save このスクリプトをGitHub Actionsワークフローやgitのpost-mergeフックで実行し、自動的にプロジェクトファイルを統合するようにしています。 #!/bin/sh PROJECT_FILE=MyProject.xcodeproj bundle exec ./scripts/clean_pbxproj.rb DIFF=$(git diff $PROJECT_FILE) if [ ! "$DIFF" = '' ]; then echo "Project file is not clean; Please check-in $PROJECT_FILE" echo "$ git add $PROJECT_FILE; git commit -m \"chore: Merge\"" fi ビルド時に SwiftFormat What's New セクションのテキストは、日米のマーケティングチームに毎回準備してもらう必要があります。こちらでは GitHub に専用のリポジトリを用意し、次のバージョンに対応するファイルを自動生成するようにしました。リリース日の数日前のタイミングで、そのリンクをマーケティングチームに対して Slack で通知するようになっています。できあがったテキストは Fastlane 経由で登録します。 以下のような形式で、GitHub 上で編集してもらいます。 これらの取り組みにより、チームが拡大しつつも開発の勢いを落とすことなく数多くの機能をリリースすることができました。 改めて、取り組んでみてよかったことを挙げてみます。 - リリースサイクル: 機能をリリースして検証するまでの期間が短縮された - 同じ機能が iOS と Android で同時にリリースできるようになった (片方を待たなくてよくなった) - リリース作業: 誰でもリリース作業ができるようになった - オペレーションミスが減り、また、ミスがあっても気づきやすくなった - 開発フロー: 手作業のマージが減った - pull request がスムーズにレビューおよびマージされるようになった なおリリースサイクル短縮の取り組みはトップダウンでしたが、自動化スクリプトなどボトムアップの提案がいくつもあり、チームワークという点でも良かったと思います。 現在、開発やリリースのオペレーションは円滑に回っている状況ですが、コードベースの成長に伴い、新しい課題も増えつつあります。SmartNews アプリはリリースしてからすでに 8 年が経過し、レガシーコード (legacy code) もそれなりに蓄積されてきました。目の前の開発だけでなく、長期的な課題にも対処していく必要に迫られています。その一環として例えばシナリオベースの自動テストの導入なども行なっており、そのような取り組みに対しても紹介できればと思っています。 スマートニュースでは「世界中の良質な情報を必要な人に送り届ける」というミッションのもと、よい体験をユーザーに届けるための開発を行なっています。iOS だけでなく幅広い職種の開発者を募集しております。ぜひ SmartNews Careers をご覧ください。 ![Notion のテンプレート](https://developer.smartnews.com/blog/images/2021/05/checklist1.png) ![リリースチェックリスト](https://developer.smartnews.com/blog/images/2021/05/checklist2.png) ![以前の開発フロー](https://developer.smartnews.com/blog/images/2021/05/gitflow.jpg) ![現在の開発フロー](https://developer.smartnews.com/blog/images/2021/05/tbd.jpg) ![auto cherry-pick](https://developer.smartnews.com/blog/images/2021/05/auto-cherrypick.png) ![What's new](https://developer.smartnews.com/blog/images/2021/05/whats-new.png) ![Team activity](https://developer.smartnews.com/blog/images/2021/05/pull-requests.png)

iOSアプリの週次リリースを支える技術

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト