ワンボタンモバイルアプリケーションのリリース

こんにちは！私の名前はミハイルブルガコフ（いいえ、親類ではありません）です。私はBadooでリリースエンジニアとして働いています。5年前に、この記事で詳しく説明したiOSアプリケーションのリリースの自動化を開始しました。その後、Androidアプリケーションを取り上げました。



今日はいくつかの結果を要約します。この間に私たちが何を達成したかをお話しします。簡単に言えば、プロセスに関わるすべての従業員は、数回のクリックで、両方のプラットフォーム上で少なくともすべてのアプリケーションをリリースできます。したがって、2019年のリリースエンジニア部門では、約830時間を節約できました。



詳細について-カットの下で歓迎！

モバイルリリースの背後にあるもの

Badooのアプリリリースには3つのフェーズがあります。

1. 開発。
2. : , — , App Store Google Play.
3. , -.

アプリケーションが完全に準備ができており、最初の段階に合格した場合、リリース段階でそれを修正せずに、製品を「カウンター」に持ってくることが重要です。この最後の手順が最も簡単なようですが、実際には多くの時間がかかり、その成功は少数の人々にかかっています。



ほとんどの時間は、App StoreまたはGoogle Playでのアプリケーションショーケースの準備に費やされています。美しいスクリーンショットをアップロードし、魅力的な説明を作成し、インデックス作成を最適化するために最適化し、検索用のキーワードを選択する必要があります。アプリケーションの人気は、この作品の品質に直接依存します。つまり、実際には、開発者、テスター、デザイナー、製品マネージャー、マーケティング担当者-製品の作成に関わる全員の活動の結果です。



アプリケーションが複数の言語で存在する場合、ショーケースを準備するために少なくとも別の人物または複数の従業員が必要です：説明のテキストを書き、すべての言語への翻訳を整理し、スクリーンショットを作成するための技術仕様を準備するプロダクトマネージャー、スクリーンショットを作成するデザイナーオーバーレイされたテキスト、デバイスの概要など、そしてもちろん、すべてのスクリーンショットとテキストを異なる言語に翻訳する翻訳者。



最後の作業は、リリースプロセス自体です。小規模なリリースエンジニアリングチームでは、かなりの時間がかかります。この非常に重要な、しかし日常的な段階で、エラーの数と人的要因の影響を最小限に抑えようとしました。これを行うには、まず、メタデータ（アプリケーションショーケースのテキストおよびグラフィックデザイン）のロードを自動化する必要がありました。これにより、時間コストを大幅に削減し、ビジネスリリース（たとえば、バレンタインデーのアプリケーションのスタイル設定）をすばやく実装できます。



Badooでのリリースのためのアプリケーションの準備についての決定はQAエンジニアチームによって行われるため、リリース開始の「赤いボタン」を押す権利を彼らに与えることにしました。同時に、モバイルデバイスからでも（スクリプトの進行状況を視覚的に表示して）アクセスできるようにしたいと考えました。

自動化に向けた最初のステップ：メタデータのロード

それが最初にどのように機能したか：リリースごとに、テーブルがGoogleスプレッドシートで作成され、製品マネージャーが検証済みのマスターテキストを英語でアップロードし、その後、翻訳者が特定の国、方言、および対象者に合わせてそれを適合させた後、リリースエンジニアがすべての情報を転送しました。 App StoreまたはGoogle Playのこの表から。



自動化に向けた最初のステップは、テキストの翻訳を全体的な翻訳プロセスに統合することでした。私はこれについて詳しく説明しません-これは別の大きなシステムです。これについては、私たちの最近の記事で読むことができます。主なポイントは、翻訳者がタブレットで時間を無駄にせず、インターフェースを使用して手作業で簡単にロードできるようにすることです（読み取り：ctrl + c ctrl + v）。さらに、バージョニングの仕組みとInfrastructure-as-Codeの基盤があります。



同時に、データベースからの既製の翻訳のアンロードと、それらの実装を、組み立てられたIPAファイル（iOSアプリケーションのファイル拡張子）に追加しました。アプリケーションはTeamCityで構築されています。したがって、アプリケーションの各バージョンは、アセンブリプロセスに手動で介入することなく、常に新鮮な翻訳が行われていました。



しばらくの間私たちはこのように住んでいました、そして一般的に、すべてが私たちに適していました。しかし、アプリケーションの数が増え、それに伴って各リリースを準備する時間も増えました。





2015年現在の私たちの現実



スクリーンショットの現在のバージョンが存在する場合の1つのアプリケーションのリリースには、iOSの場合、リリースエンジニアによる平均1時間半から2時間、Androidの場合、約30分かかりました。違いは、iOSアプリケーションがいわゆる処理を通過する必要があるという事実によるものです。これには時間がかかります（処理が正常に完了するまで、アプリケーションをレビューに送信することは不可能です）。また、当時のほとんどの操作では、App Store自体がGoogle Playよりもはるかに低速でした。



アプリケーションをストアに配信するための追加のツールが必要であることが明らかになりました。そしてその瞬間、Fastlaneと呼ばれる製品がオープンソース市場で人気を博し始めました。彼はその時まだ湿っていたという事実にもかかわらず、彼はすでに私たちの問題の膨大な層を解決することができました...



さらに説明する内容を明確にするために、彼について少し説明します。

一目でファストレーン

現在Fastlaneは、開発が完了した瞬間から、App StoreやGoogle Playでのアプリケーションのリリースまで、すべてのアクションをほぼ完全に自動化できる製品です。テキスト、スクリーンショット、アプリケーション自体をダウンロードするだけではありません。ここでは、証明書の管理、ベータテスト、コード署名などを行います。



「若さ」と不安定さの中で、Fastlaneを知りました。しかし今では、製品をユーザーに提供するという時間のかかる大きな問題に直面している多くのモバイルアプリケーション開発チームにとって、自信を持って機能し不可​​欠なコンポーネントです。それについて最も興味深いことは、メインコンポーネント用の独自のプラグインを作成し、コミュニティによって作成されたプラグインを使用する機能です。... このような特定の製品の場合、これは優れたソリューションであり、DevToolsで「余分な」テクノロジーを作成しないようにする（重要です）ことができます。



また、Fastlaneの創設者であり主要な開発者がGoogleに採用されたという自信を呼び起こします。このコンポーネントは、コミュニティだけでなくそれ自体もサポートするようになりました。



時間の経過とともに、Fastlaneが提供するほとんどの機能を、アプリケーションのビルド、署名、入力などのシステムに実装してきました。そして、彼らはそれについて信じられないほど幸せです。CI / CDシステムで回転する統一されたスクリプトを一度に作成できるのに、なぜホイールを再発明し、その正しい形を維持するのですか？

IOSリリースの自動化

Google Playは開発者にとってより親しみやすいという事実により、Androidアプリケーションをリリースするのにほとんど時間はかかりませんでした。テキスト、ビデオ、スクリーンショットを更新せずに数分でした。したがって、自動化の必要性の欠如。しかし、App Storeの場合、問題は非常に明確でした。アプリケーションをレビューに送信するのに時間がかかりすぎました。そのため、iOSで自動化を開始することにしました。



App Storeとの対話を自動化するためのシステム（およびプロトタイプを作成すること）の類似性について考えましたが、完了して更新するためのリソースがありませんでした。また、Appleからの多かれ少なかれ適切なAPIはありませんでした。さて、カスタムソリューションの棺桶の最後の釘は、App Storeとそのメカニズムに対する定期的な更新によって引き起こされました。一般的に、2015年の別のバージョンであるFastlaneを試すことにしました。



最初のステップは、アプリケーションの翻訳されたテキストを、一般的なAIDA（自動対話型展開アシスタント）内部システムのコンポーネントとして目的の構造にアップロードするメカニズムを記述することでした。このシステムは一種のハブであり、Badooで使用されるすべてのシステム、テクノロジー、コンポーネント間のリンクです。 GolangとMySQLで実装された自己記述型キューイングシステムで動作します。主に部門リリースエンジニアリングを維持および改善します。2013年の記事でそれについて詳しく説明しましたが、それ以来多くのことが変更されています。私たちはそれについて再び話すことを約束します-AIDAはクールです！



次のステップでは、アップロードされたテキストがFastlaneに送られ、FastlaneがそれらをApp Storeにアップロードしました。その後、App Storeインターフェースに移動し、ダウンロードしたいバージョンを手動で選択して、検証のためにアプリケーションを送信する必要がありました（その時点で処理がすでに完了している場合）。



これにより、リリースの準備時間は数時間から約30分に短縮されましたが、そのうちの1分半だけを手作業で行う必要がありました。残りの時間は待つことです。処理が終了するのを待ちます。 AppStoreをリリース用に準備するときの手作業からほぼ完全に救われたので、このメカニズムは当時まさに画期的でした。スクリプトのリポジトリを作成し、リリースに直接関係する人（プロジェクトマネージャー、リリースエンジニア）にアクセスを許可しました。



このモードでは、しばらくの間住んでいました。しかし、ある時点で、この計画は多くの「神聖な知識」の蓄積につながり、その所有者、そしてその結果、出来事の全体像は一人になり、これは良くありません。特にこの人自身のために：あなたはラップトップなしで休暇に行くことさえできません。



さらに、このメカニズムの周りには、互いに実質的に無関係な多数のインフラストラクチャコンポーネントが散在していました。

1. TeamCityに行って新しいビルドを作成し、そこからIPAファイルをダウンロードして、アプリケーションマネージャーからApp Storeにアップロードする必要がありました。
2. 次に、AIDAの翻訳のあるインターフェイスに移動し、すべての翻訳の準備ができているかどうかを確認し、スクリプトを実行して、正しく機能することを確認します（結局、Fastlaneはまだ湿っていました）。
3. App Store , Processing.
4. Review.

そして、それぞれのアプリケーションで。その時に私たちが8を持っていたことを思い出させてください。



次のステップは、スクリプトがAIDAに転送されると同時に、アプリケーションが送信されるまですべてのステップを組み合わせて自動化することでした。翻訳の準備状況の確認、TeamCityからのデータの収集、通知、ロギング、および21世紀の他のすべての利点です。これと並行して、ビルド段階ですべてのビルドバージョンをTestFlightにアップロードし始めました。



TestFlightはサードパーティ製のアプリケーションであり、Appleが購入した後、外部のテスターがほぼ本番環境で、つまりプッシュ通知などを使用して完成したアプリケーションをテストします。





AIDAよくやった、AIDAのように！



これにより、すべてのことについてすべての時間が30分から1.5分に短縮されました。QAエンジニアリングチームがリリースを開始する前に、IPAファイルは処理を通過する時間がありました。それでも、App Storeにアクセスし、正しいバージョンを選択して、レビューに送信する必要がありました。



さらに、シンプルなインターフェースが描かれました。私たちは皆、クリッククリックが大好きです。





このように、タブごとに、Ctrl + C Ctrl + V ...

Androidリリースオートメーション

次に、Androidアプリケーションのリリースの自動化についての質問がありました。このプロセスははるかに高速でしたが、手作業でかなり多くのことを行う必要がありました。

1. Google Play Consoleに移動して、前のバージョンがユーザーの100％にロールアウトされているか、フリーズされていることを確認します。
2. 更新されたテキストとスクリーンショット（ある場合）を使用して、リリースの新しいバージョンを作成します。
3. APKファイル（Androidパッケージ）をアップロードし、マッピングファイルをアップロードします。
4. HockeyApp（その時点でのクラッシュのロギングに使用）に移動し、APKファイルとマッピングファイルをそこにアップロードします。
5. チャットに移動し、リリースステータスについて登録解除します。

そして、それぞれのアプリケーションで。



はい、Google Playには独自のAPIがあります。しかし、iOSのリリースでFastlaneを既に使用している場合、なぜラッパーを作成し、プロトコルの変更を監視し、それを維持し、不必要にエンティティを生成するのでしょうか。さらに、それは私たちのサーバーに快適に存在し、独自のジュースで沸騰し、一般的に更新されます。そしてその時までに、彼はAndroidアプリケーションを適切にリリースすることも学びました。星が集まった！



至る所で最初に目にしたのは古いものすべてでした：個別のスクリプト、自動化スケッチ、APIの古いラッパー-これは実験として一度作成されただけで、あまり価値がありませんでした。その直後、チームをAIDAに追加しました。チームはAIDAに必要なものをTeamCityから取得する方法、HockeyAppに必要なものをロードする方法、アラートを送信する方法、アクティビティをログに記録する方法をすでに知っていて、通常はチームのメンバーでした。



Fastlaneは、Google PlayでのAPKおよびマッピングファイルの入力を処理しました。打たれた道をたどる方がはるかに簡単だと言わざるを得ません。それは最小限の労力で十分迅速に実装されました。



自動化の実装の特定の段階で、APKアーカイブからAAB（Android App Bundle）への移行が発生しました。繰り返しになりますが、私たちはすぐにすべてを修正することができたので、とても楽しかったですが、この移行に関連して「エンターテイメント」が追加されました。たとえば、彼はHockeyAppを台無しにしましたが、自己解凍の準備に関連してAABアーカイブを使用する方法を知りませんでした。したがって、快適に使用し続けるには、AABをアセンブルした後、アセンブルされたアーカイブを分解し、そこからマッピングファイルを取得してHockeyAppに移動し、AABからAPKファイルを個別に収集して、同じHockeyAppにアップロードする必要がありました。楽しそう。同時に、Google Play自体がAABを完全に分解し、そこからマッピングファイルを取り出して、必要な場所に挿入します。そのため、1つのステップを取り除き、いくつかのステップを追加しましたが、どこにも行きません。



新しいバージョンのダウンロード、リリースの確認、現在のアクティブなリリースの管理（ロールアウトの割合の増加など）が可能なインターフェースが（これもiOSと同様に）作成されました。このフォームでは、Android QAチームのリリースチームメンバーにそれを渡し、フィードバックの収集、バグの修正、ロジックの完成を始めました（リリース1.0の後に他に何が起こりますか？）。



ちなみに、将来的には、自動化により、ベータ版のアプリケーションをスケジュールに従って自動的にGoogle Playにアップロードできるようになり、自動テストと回帰テストのプロセスが大幅に加速しました。

モバイルリリースのフローの統一

Androidのリリースが自動化される頃には、FastlaneはついにiOSアプリケーションのバージョンをレビューのために送信する方法を学びました。また、AIDAのバージョンチェックシステムを少し改善しました。



iOSのリリースをQAチームに外部委託するときがきました。これを行うために、iOSアプリケーションのリリース中に発生するニーズを完全にカバーする美しいフォームを描くことにしました：事前定義されたパラメーターに従ってTeamCityで目的のビルドを選択し、ダウンロードしたテキストのオプションを選択し、オプションのフィールドを更新するかどうかを選択します（たとえば、プロモーションテキスト） ...



否や言うほどない。クッキーカッターはとてもきれいで、すべての要求を完全に満たしていることがわかりました。さらに、その実装により、必要なすべてのパラメーターを使用して必要なすべてのアプリケーションを一度に選択できるようになり、インターフェースとの対話が最小限に抑えられました。 AIDA on commandは、ビルドログへのリンクを送信します。これにより、発生したエラーを追跡し、すべてが正常に行われたことを確認し、ダウンロードしたIPAファイルのバージョン、リリースバージョンなどのデバッグ情報を取得できます。これがiOSの美しいリリースです。 iOS QAチームに転送されました。





さて、かわいいですか？



金型のアイデアがとても気に入ったので、Androidのリリースでも同じようなものを作ることにしました。一方、完全にReact Nativeで記述されたアプリがあり、そのアプリのQAチームがiOSとAndroidの両方のリリースを担当しています。



Android QAチームがすでに使用しているインターフェースは、変更と同様の形式に統合され、プロセスは新しい現実に適応されました。すべてがiOSチームのプロセスに可能な限り近くなりました。これにより、両方のプラットフォームのドキュメントの最終バージョンをほぼ最終的にスケッチする（絶え間ない変更の過程で、これを行うことは絶対にしたくありませんでした）とともに、歴史的に発展し、非標準的な状況で不要なジェスチャーにつながり、必要なジェスチャーにつながるすべての人為的な制限からリリースプロセスを切り離すインセンティブを与えましたリリースエンジニアのチームの行動。

出力

そのような退屈な方法で、（モバイルの方向性の開発を開始してから現在に至るまで）約5年間で、構築、テスト、およびリリースのプロセスを完全に自動化し、それらを可能な限り効率的にし、リリースの責任をQAチームメンバーに移しました。アプリケーションの準備の程度に関する決定。



明らかな利点に加えて、1人の人間に結びついたあらゆる種類の「秘密の知識」である散在するスクリプトを完全に排除し、リリースエンジニアの小さなチームがサポートする新しいコンポーネントをエコシステムに統合しました。



エンジニアが必要なときにいつでもコードを記述できるようになり、複雑なインターフェースを掘り下げる貴重な時間を無駄にすることなく、サードパーティの開発者がコードをサポートできるようになりました。 「どこにチェックを入れればよいですか」などを理解するのは特に困難です。時計が真夜中のとき、誰もオフィスにいないので、ここにホットフィックスをアップロードする必要があります。



5年。なぜそんなに長いの？まず、モバイルリリースは私たちの小さなチームの責任の唯一の領域から遠く離れています。第二に、もちろん、新しいオープンソースプロジェクトFastlaneの開発には時間がかかりました。私たちのリリースシステムはそれとともに進化しました。



私たちはこの分野で長い道のりを歩んできました。多分それは最も効果的ではないかもしれません、おそらくいくらかの熊手が予見されて迂回されたかもしれません。しかし、それはそのままでした。私たちがそれを始めたとき、この種の同様の記事はありませんでした-私たちは私たち自身の方法を作りました。そして、もしあなたが今、同じような仕事に直面していて、この記事が何かを助けるなら、私はとても幸せです。しかし、根本的に新しい情報が得られなかったとしても、少なくともあなたが暇なときに読むことが面白かったと思います。そして、おそらく、あなたの経験と比較してください。そして、このトピックについて何か言いたいことがあれば、コメントへようこそ！