Hero Image
eyLogがモバイルリリースを管理する方法

コンテキスト App StoreやPlay Storeでのアップデートの定期的なリリースは、特に複数のアプリを同時に管理する場合、思っている以上に複雑です。異なるチームのワークフローを探ることは興味深いものです。共通点や相違点を明らかにすることで、有益な戦略が見つかる可能性があります。ここでは、eyLogのモバイルリリース管理についての概要を紹介します。 リリースサイクルの概要 私たちのリリースサイクルは、多くの企業が行っていることと非常に似ています。以下は、私たちがどのように管理しているかの簡単な説明です: 私たちは毎月新しいバージョンをリリースしているので、毎月リリースカットを行います リリースカットが行われたら、すぐにテストが始まります。主要な問題を修正するためには約1週間の時間があり、その間にリリースブランチに修正を追加していきます テストと修正が完了した後、通常月の中旬にApp Storeレビューにアプリを提出します。このタイミングで、もし審査での拒否や遅延があった場合に余裕を持つことができます 承認を得ると、ビルドは月末までリリースの準備を整えておきます リリース当日、私たちは自動更新で小規模なユーザーグループにフェーズリリースでアップデートを展開します。これにより、テストで見逃した大きな問題を早期に発見することができます 新しいリリースのパフォーマンスを慎重に監視した後、7日目には全ユーザーへの展開を加速させます この間に、次のリリースの準備も始めているので、サイクルは連続的に進行します コミュニケーションの管理 リリースやロールアウト中にコミュニケーションを明確で整理されたものに保つために、各リリースごとにCliqチャンネルを作成します。例えば、#ios-release-6-1-0 のように。この方法により、特定のリリースに関する更新情報や議論を一元化することができ、他のチャンネルでの気が散る情報を減らし、過去のリリースに関する情報も簡単に見つけることができます。 専用のCliqチャンネルを持つことは、ホットフィックスを発行する際に特に有用です。私たちは毎週更新をリリースしているので、既存の問題に対するホットフィックスは、2つのリリースが同時に行われることを意味します。それぞれのリリースのコミュニケーションを独立したチャンネルで行うことは、混乱を避けるために重要です。例えば、バージョン6.1.0のホットフィックスに関連する内容は#ios-release-6-1-0で議論され、次のバージョン6.2.0に関する議論は#ios-release-6-2-0で行われます。 リリース候補のテスト 私たちのアプリは非常に大きいため、リリース候補のテストを1人または少人数のグループで全て処理することは不可能です。品質保証(QA)チームだけでは、毎週行われる重いテストに追いつくことができません。多くの変更や新機能が迅速に開発されているため、正しいテストが行われているかを確認することが難しいです。実際に機能を開発している人々が、何が新しいのか、何が変更されたのか、どのようにテストすべきかを最もよく理解しています。 そのため、リリース候補のテストには「ウォッチドッグ」と呼ばれるエンジニアグループを頼りにしています。このグループはバックエンド、フロントエンド、モバイルエンジニアで構成されており、それぞれが自分の担当するアプリの部分をテストします。ウォッチドッグは、テスト中に見つかった問題を修正するか、修正を他の人に委任します。各部分は通常、私たちのプロダクトチームに対応しており、例えばログインチームはアプリのログイン機能をテストします。ウォッチドッグは、承認する前に必ず実行しなければならないテストを持っており、すべてのコンポーネントが承認されてからリリースをレビューのために提出することができます。 リリース候補のテスト中に発生した問題の処理 ウォッチドッグがリリース候補のテスト中に問題を見つけた場合、彼らはチームと協力して問題を解決し、標準的なプルリクエストを使用してメインブランチに修正を加えます。修正がマージされた後、その修正は「チェリーピック」というプロセスを通じてリリースブランチに追加される可能性があります。しかし、変更を最後の瞬間に加えることはリスクを伴うため、リリースに含めることができる内容には厳格なルールがあります。 私たちは、ユーザー体験に影響を与える重大な問題や新たに発生したバグの修正は許可しますが、ユーザーに影響を与えない軽微なバグ修正や、締切を過ぎた新機能を追加することは許可していません。修正リクエストをレビューするシステムを開発しており、チームは問題を説明し、証拠を提供するリクエストを提出し、それをリーダーが確認します。 リリース後のホットフィックスのプロセスは、リリースサイクル中のチェリーピックのリクエストに似ていますが、ルールはさらに厳格です。ホットフィックスを作成するにはより多くの労力が必要で、今後の通常のリリースに干渉する可能性があります。リリースサイクルの遅い段階でバグが発見された場合(アプリがレビューに提出された後、公開前など)、修正するかどうかは、リリース後のホットフィックスと同じ厳格なルールに基づいて決定されます。 更新がまだ公開されていなくても、レビュー待ちやすでに承認されている場合があります。これを修正するには、現在のビルドを却下してアプリを再提出する必要があります。これによりリリースが遅れる可能性があるため、修正が必要かどうか、またその処理方法をケースバイケースで評価します。ビルドを却下して修正を適用し、再提出することもあれば、予定通りリリースを実施し、後でホットフィックスを発行することもあります。あるいは、バグがホットフィックスを必要とするほど重大でないと判断し、次のリリースサイクルで修正することを選択することもあります。 リリース後のロールアウトの監視 リードと担当開発者は、リリース後の監視を共同で担当しています。私たちはNew RelicとFirebaseを活用して、クラッシュやシステムの健全性を追跡しています。リードが異常を検知した場合、担当開発者に詳細な調査と必要な修正を指示します。一方、問題が発生しない場合、自動的にフルロールアウトに進むことが可能です。

Hero Image
Beedaにおけるキャッシュ管理戦略の最適化

高速でシームレスなユーザー体験を提供するためには、すべてのアプリケーションに効果的なキャッシュシステムが必要です。キャッシュがない場合、アセットを繰り返しダウンロードすることで大量のリソースが消費され、読み込み時間が遅延する可能性があります。この問題を解決するために、開発者はパフォーマンスを向上させ、遅延を最小限に抑えるために、ディスクキャッシュ、LRU(Least Recently Used)キャッシュ、データベースキャッシュなど、さまざまなキャッシュ戦略を利用します。 問題: Beeda Userアプリでは、画像、Lottieアニメーション、ビデオといったメディアアセットを効果的に扱うことが、高速でシームレスなユーザー体験を実現するために不可欠でした。それぞれのメディアアセットには、キャッシュや最適化に関する特有のニーズと課題があります。 画像: 高解像度の画像は大量のメモリとストレージを消費する可能性があるため、ディスクキャッシュ(例: URLCacheやSDWebImageのようなサードパーティライブラリを使用)が重要です。 Lottieアニメーション: Lottieファイル(JSONベースのアニメーション)は軽量ですが、効率的なパースとレンダリングが求められます。インメモリキャッシュ(例: NSCache)を使用することで、繰り返しパースする際の負荷を軽減できます。 ビデオ: ビデオはサイズが大きいため、ストリーミングや部分的なキャッシュが必要で、過剰なメモリやストレージの使用を防ぎます。 各キャッシュ機構が特定のメディアタイプに対して効果的である一方で、次のような重要な課題が浮かび上 実装: Beeda Userアプリにおけるメディアアセット管理の課題に対処するため、各タイプに応じた異なるユーティリティ(Utils)を設計しました。この構造化されたアプローチにより、画像、Lottieアニメーション、ビデオなどのアセットを効率的に処理できます。 1. ユーティリティレイヤー (Utils Layer) 各メディアアセットタイプには、それぞれのタスク(ダウンロード、パース、処理など)を担当するユーティリティクラスがあります。これらのユーティリティは、アプリが直接操作することなく、アセットマネージャーからアセットを取得する中間役として機能します。 例えば、画像ユーティリティを考えてみましょう。もし画像がすでにキャッシュされていなければ、このユーティリティはアセットマネージャーのgetDataメソッドを呼び出して画像をダウンロードします。ダウンロードが完了すると、ユーティリティは生データをアセットマネージャーに渡して保存します。 protocol ImageUtilProtocol { func downloadImage(url: String, imageCompletionHandler: ((UIImage) -> Void)?, storageType: StorageType) } 2. アセットマネージャー (Assets Manager) アセットマネージャーはシステム内の中間レイヤーとして機能し、ユーティリティ(Utils)とさまざまなキャッシュメカニズムの間のブリッジとして働きます。主な役割は、指定されたストレージタイプに基づいて、どのキャッシュ方式を使用するかを決定することです。 StorageTypeパラメータは、利用可能なキャッシュメカニズム(例: インメモリ、ディスク、ハイブリッドなど)を定義します。 enum StorageType { case lru(LRUCacheType) case disk } enum LRUCacheType: String { case lottie case image case video } アセットマネージャーには、データを保存および取得するための共通メソッドがあります。 protocol AssetsManagerProtocol { func writeData(data: Data, forKey key: String, storageType: StorageType) func readData(forKey key: String, storageType: StorageType) -> Data? func removeData(forKey key: String, storageType: StorageType) } アセットマネージャーは、キャッシュ操作の管理において重要な役割を果たします。ユーティリティクラスがそのメソッドを呼び出すと、アセットマネージャーはstorageTypeに基づいて適切なキャッシュレイヤーを決定します。その後、データの書き込み、読み取り、または削除といったタスクを該当するキャッシュメカニズムに委任し、効率的かつ正確にアセットを処理します。

Hero Image
BeedaのSwiftコンパイル時間を83%改善

コンテキスト Beedaの新機能拡張に伴い、コンパイル時間が深刻な問題となってきました。些細な変更やフルコンパイルに約11分もかかるため、開発ワークフローに大幅な遅延が生じていました。 生産性を向上させ、開発の効率を改善するために、このコンパイル時間を劇的に短縮することを目指しました。この記事では、どのようにしてコンパイル時間を2分にまで短縮したかを紹介します。 Xcodeの最適化レベル Xcodeでは、以下の3つの最適化レベルから選択できます: なし 高速 全モジュール最適化を使用した高速 これらの設定を活用して、どのようにこの改善を実現したかを紹介します。 「全モジュール最適化」を有効にすることで、コンパイルプロセスが大幅に加速されます。しかし、「高速」または「全モジュール最適化を使用した高速」設定を選択すると、デバッグ機能が無効になります。これらのオプションのいずれかを選択し、アプリをコンパイルした後にデバッグを試みると、コンソールに次のメッセージが表示されます: アプリは最適化されてコンパイルされました - ステッピングは異常に動作する可能性があり、変数が利用できないことがあります。 解決策:ユーザー定義設定を追加する 全モジュール最適化を有効にするには、Xcodeプロジェクトの設定にユーザー定義設定を手動で追加する必要があります。以下はその方法です: 手順 プロジェクト設定に移動: プロジェクトナビゲータでプロジェクトを選択します。 ビルド設定タブに移動します。 ユーザー定義設定を追加: ビルド設定ペインの左上隅にある**+**ボタンをクリックします。 ユーザー定義設定の追加を選択します。 設定名をSWIFT_WHOLE_OPTIMIZATION_LEVEL(または他の関連する名前)にします。 値をYESに設定して、全モジュール最適化を有効にします。 Debug設定でNoneを設定 ターゲットのビルド設定で、Debug構成の最適化レベルをNoneに設定します。 この改善がBeedaに与える影響 コードを頻繁に更新し、反復しているiOSチームにとって、この改善は効率の向上、コストの削減、顧客体験の向上に大きな役割を果たしています。具体的に言うと、1日30回のコンパイルを実行する場合、この最適化は1日に約26時間のコンパイル時間を節約します。この時間の節約は、3人の追加の開発者のアウトプットと同じくらいの効果があります。