🤰🏻 🆎 👩‍⚖️ 列車を解放します。Yandexレポート 🚵 🔄 ✍🏽

さまざまなYandexチーム（および大規模なIT企業）でのリリースプロセスは、同様の方法で構成されていますが、多くの詳細が異なります。モバイルデベロッパーには固有の仕様があります。リリースは、App StoreおよびGoogle Playでのレイアウトの順序によって影響を受けます。Android開発者Dmitry PolyakovDmpolyakov 彼は彼の周りのプロセスについて話しました-彼のチームがスケジュールでリリーストレインを送信する方法、予定外のリリースを開始する方法、すでに残されたリリースに車を追加する方法、そして順調に進むために何をすべきか。

-皆さん、こんにちは。私は、私が採用するモバイルアプリケーションのAndroid開発者であるDmitry Polyakovです。

現在、2つのチーム（AndroidとiOS開発）を使用しています（それぞれ13人）。これにより、多くのクールなタスクを並行して実行し、それらをユーザーにすばやく展開できます。レポートでは、gitを使用して1つのリポジトリーに住む方法を学びました。

次に、リリースサイクルの仕組みについて説明します。マネージャーが来て、この機能をできるだけ早く展開したいと言っています。おそらく、おそらくすべてのマネージャーが望んでいるので、毎週App StoreとGoogle Playに行くようにリリースプロセスを設定しました。私たちが持っているツールについてもお話しします。ぜひ試してみてください。クールです。

Gitフロー

Git Flowから始めましょう。基本として、私たちはクラシックなGit Flowを採用しましたが、私たちの状況やチームの下では、状況は大きく変化しました。あなたも見えます、そしておそらくこれからの何かがあなたに合うでしょうが、何かは似ていません。各チームはgitを使用する独自のアプローチを持っています。

どのように機能しますか？ Epicは、いくつかの優れた機能のために、機能のルートブランチです。より明確にするために、製品の例をすぐに見てみましょう。

マネージャーが来て言う-開発者は、アプリケーションで選択した製品を使用してウィッシュリストの機能を作成します。開発者は新しいブランチエピックを開始し、ウィッシュリストと呼びます。

さらに、トラッカーで始まる小さなタスクに分解します。おそらく、これはネットワークでの作業、UIのレンダリング、テストの作成です。そのような機能ごとに、彼はトラッカーでタスクを開始します。そして、タスクの完了を開始するとすぐに、対応する機能ブランチを開始します。同じエピックから彼女をブランチします。

彼はそのような機能の1つで作業を終えるとすぐに、プールリクエストを通じてそれをエピックに注ぎます。プールリクエストは、チームの他の開発者がコードをチェックするときのメカニズムです。彼らが何かを好まない場合、あなたのコードはあなたの叙事詩に届かないかもしれません、それは彼らとの合意を見つけるまであなたが解放されないことを意味します。

私たちのチームにはこれらのレビュー担当者が2人います。それらはランダムに割り当てられます。これは自動化されたプロセスであり、プールリクエストで変更したのと同じファイルを最近使用した開発者から選択されます。

したがって、独自の機能セットを備えたいくつかのエピックがプロジェクトに並行して存在していることがわかります。エピックは1つの機能のみを持つことができます。これは、epicへのプール要求を通じてこの機能をアップロードする場合に発生する可能性があります。

1つのエピック内のすべての機能の作業が完了するとすぐに、タスクは最初にテストチーム、QAチームを離れ、ブランチを機能的にテストします。彼らがバグを見つけたら、あなたはこの叙事詩の一部としてそれらを編集します。すべてのバグが修正されたら、このエピックを開発に組み込みます。ここでは、epicの機能の段階ですべてのコードが確認されているため、チームによる追加のコードレビューは既に行われていません。

私たちの開発は、エピック段階でテストされ、コードがプール要求を通過するため、すでにテスト済みのコードがアクセスするようなブランチです。

これにより、リリースサイクルの最初に新しいリリースブランチを安全に作成できます。まだテストされていないバグがたくさんあることを恐れずに。したがって、開発から新しいリリースブランチを作成しています。テスト中です。リリースがテストされ、ゲートに進む準備ができるとすぐに、このブランチはマスターにマージされます。

ホットフィックスがあり、別のブランチタイプがある場合があります。これは非常に短いリリースであり、すぐに公開する必要があります。次のリリースサイクルが始まるまで3日または4日待つ時間はありません。通常、これは小さなものです。

たとえば、ある種のバグが本番環境に入って非常に重大な場合は、早急に修正する必要があります。したがって、現在のリリースを停止し、このバグの修正プログラムを実行して、リリースを更新します。ただし、ホットフィックスは常にバグについての話ではありません。時には製品のニーズがあります。

たとえば、モスクワで自己分離モードが導入されるとすぐに、ユーザーが非接触で製品を注文できるようにするための製品が必要になりました。これで、アプリケーションで注文するときに、ユーザーは「ドアから出る」機能を選択できます。宅配便が到着し、小包をドアの下に置き、非接触であなたに渡します。

この修正プログラムのタスクには、家にいて宅配便で注文するように促すさまざまなウィジェットも含まれています。今は集荷所に行かないでください。これらのタスクは重要であると考えているため、できるだけ早くユーザーに伝えることができるように、修正プログラムを通じてこれらのタスクをロールアウトしました。

ホットフィックスがある場合、マスターからブランチします。開発からそれをブランチにすることはできません。その時点で、まだリリースされていない新しいエピックを開発できるからです。しかし、これらの叙事詩をホットフィックスに持ち込みたくないので、ランダムに影響を与えたり、ホットフィックスをブロックしたりすることはありません。修正プログラムが完了した後、このコードはまだ開発に存在していなかったため、マスターに挿入し、開発に追加します。

マスターは、アプリケーションの最新バージョンに対応するコードベースであり、現在ユーザーのストアにあります。機能テストとリグレッションテストはすでにそこに合格しているため、バグがなく、クリーンです。これはバックアップブランチです。

リリースが完了したら、開発に注ぎ込みます。リリースの一部として、機能テストでは発見されなかったバグが見つかり、異なるエピックが互いに競合する可能性があるためです。したがって、開発にもこれらの修正が含まれるように、リリースを開発に注入します。

エピックに対して多くの作業を行うことができます。開発中のコードに追いつくために、開発者はそれをエピックに追加する場合があります。これにより、フリーズの競合が少なくなります。

エピックに開発を追加したので、同じ理由でエピックを機能に追加する必要があります。

エピックブランチとフィーチャーブランチの名前には、タスクトラッカーにチケット番号があります。これは、アプリケーションのどの部分からでも完全に確認できるチケット番号によって正確にわかるため、変更されたチケット、変更されたチケット、このコードを作成した人、およびコードがどのような目的のために作成されたのかが正確です。

リリースおよびホットフィックスブランチの名前には、アプリケーションの現在のリリースバージョン番号が含まれています。一部のチームは、修正プログラム番号をリリース番号と組み合わせて、修正プログラムは小さなものであり、おそらくユーザーにとってあまり重要ではないと言ってこれを正当化します。したがって、アプリケーションのバージョンは上がりません。製造元からのさまざまなクラッシュレポートが届くため、この方法は使用しません。このレポートがホットフィックスに含まれていたのか、リリースに含まれていたのかを正確に理解して、問題を探す場所を知りたいのです。

マスターと開発は、リポジトリに常に存在するブランチです。作成したら、ライブします。したがって、それらはとても簡潔に名付けられています。

それが私たちの生き方です。今、私たちは快適で便利です。

リリーストレイン

私たちはリリースプロセスに進みます。ただし、リリースとその構築方法について説明する前に、リリースをサポートするために必要な役割について説明します。

オンコールの開発者がおり、1週間以内に製品タスクの処理を中止し、現在のリリースのバグを修正しています。現在のリリースのタスクがない場合は、累積した技術的負債を修正し、バックログからタスクを取得して修正します。

テスターもいます。また、1週間以内に製品タスクのテストを停止し、現在のリリースを確認します。現在のリリースのタスクがない場合は、技術的負債の一部として修正された内容をテストします。

リリースは金曜日に始まります。厳しい締め切りがあるのはこの日です。夕方の18時に、当番のテスターが「リリース開始」ボタンをクリックします。この瞬間の後、ボタンをクリックするとリリースブランチが作成され、開発が追加され、そこには追加されないため、開発に注がれるすべてが現在のリリースに分類されなくなります。

もう1つの重要なプロセスは金曜日に行われます。これは、現在のリリースの別の項目です。これについては、後で説明します。

週末は休みなので、2日目は月曜日です。当番の開発者はその日を分析から始めます。現在のリリースで変更された点をコードの観点から見ています。現在のリリースブランチとマスター間のgit diffを取得します。そして、この差分によって、どのコンポーネントが影響を受けているかを調べます。チェックアウトプロセスまたはバスケットに影響する可能性があり、台座での作業には影響しません。

したがって、彼はテスト中にテストされるさまざまなケースのリストを作成します。これにより、アプリケーション全体をチェックするのではなく、回帰をスピードアップできます。リストがコンパイルされると、テストチームがアプリケーションをチェックし、担当の開発者がバグを修正します。バグが多い場合は、これらのコードを最近使用した他の開発者に一部を委任できます。

火曜日には、引き続きリリースをテストし、リリースのバグを修正します。午後に向かって、回帰テストが終了し、ゲートに向かう準備ができました。私たちはリリーストレインをリリースしました。最近、新しいマーケットプレイスに参入したためです。また、Google Playだけでなく他のサイトでも公開することをお勧めします。プラスは、あなたが新しい熱心な聴衆を得るというだけではありません。

どういうわけか、私たちはリリースを公開し、数時間後にユーザー間のバグの数が大幅に増加していることがわかりました。これらのバグを調べて分析し、Huaweiデバイスでのみ発生することを確認しました。何が起こっているのかすぐにはわかりませんでしたが、Huaweiがいて、テストし、バグを見つけて修正し、アップデートに行きました。

Google Playのアップデートが到着するとすぐに、大きなバナーが表示されました。これは、現在の世界の状況により、Google Playには非常に大きな負荷がかかり、通常のようにアプリケーションをチェックする時間がないためです。アプリケーションを確認する時間はまだないことがわかりました。GooglePlayユーザーには連絡せず、Huawei AppGalleryでのみ公開されました。そしてそれがファーウェイだけにバグがあった理由です。したがって、Google Playで公開する前でも、重大なバグを検出して修正することができました。

次に、非常に多くのユーザーがいるため、Google Playを通じてパブリケーションがどのように配置されるかを説明します。そしてHuawei AppGalleryでは、私たちは最近立ち去り、そこですべてがそこにどのように配置されているかを理解しようとしています。

Google Playのすべてのユーザーにすぐに公開するわけではないため、ある種のランダムなバグが視聴者全体に影響を与えることはありません。バグがある可能性があるという事実に同意したすべてのテスターにのみ公開しますが、私たちの変更とリリースを最初に受け取るのはテスターです。さらに、私たちは聴衆のわずか5％を公開しています。

水曜日に、当番の開発者はクラッシュのない新しいリリースを見ています。新しいクラッシュがなく、古いクラッシュが少ないことが重要です。すべてが正常な場合でも、彼は製品のメトリックをチェックします。たとえば、同じ期間に比べて注文数が減少しないようにします。製品の指標とクラッシュのないものが良ければ、さらに5％、合計10％展開します。

木曜日に、当番の開発者がストア内のレビューをチェックします。実際、彼は水曜日にそれらを監視します。確かに、水曜日にはまだ少数の聴衆がいて、1つまたは2つのレビューがあります。しかし、木曜日にはリリースを判断するためのより多くのレビューがあります。 10〜15個あるかもしれません。

メトリックとグラフがたくさんあるのに、なぜレビューを見るのですか？アプリケーションがクラッシュすることはなく、メトリックが正しい場合もある。ただし、ユーザーがフォントを使用しているか、一部のフィルターが機能していない可能性があります。私たちは、ユーザーがアプリケーションをできる限り便利に使用できるように努め、そのようなレビューを分析し、ユーザーが遭遇するバグや問題を修正します。

レビューが順調で、クラッシュフリーも正常で、製品指標が低下していない場合、すでに20％展開しています。

そして、それは私たちのリリースの発売日である金曜日に始まります。私が話したかった第三の点は、金曜日に現在のリリースを完了することです。すぐに20％から100％にロールします。それは非常に大きな飛躍と非常に危険なようです。しかし、それはチームとあなたの聴衆に依存します。

私たちの聴衆の20％は、リリースの安定性を判断する高い確率で私たちを許可します。そして、すべてが20％良好で、金曜日に問題がなければ、100分の1に進みます。

私はGoogle Playでライフハックを使用しているチームを知っています-彼もあなたを助けるでしょう。 100％ではなく99.9％で展開できます。これにより、リリースを緊急に停止するためのボタンがGoogle Playに残ります。 100％展開すると、このボタンは消えます。しかし、私が言ったように、私たちの聴衆の20％は、リリースの安定性を正確に判断できます。したがって、私たちは静かに100％にロールアウトします。これにより、追加の手順から解放されます。そして、さらに0.01％をロールする必要があります。

これが私たちのプロセスなので、毎週乗って迷子にならないようにしています。

彼の側でユーザーの良い生活をサポートするために、他にどのようなツールがありますか？これらは、強制更新、ソフト更新、機能切り替えです。

強制更新-バージョンが非常に古い場合にアプリケーションの使用をブロックするメカニズム。廃止されたと見なされるバージョンは、サーバーの管理パネルで設定されます。そして、そこで数が変更されるとすぐに、いくつかのアプリケーションはあなたを行かせないような箱を持っています。更新ボタンのみがあり、ユーザーは強制的にアップグレードされます。

このメカニズムはできるだけ使用しないようにしていますが、非常に重要な場合もあります。たとえば、下位互換性を壊した場合、古いコードでサポートされていない新しい機能をロールアウトしました。次に、古いバージョンのアプリケーションのユーザーが、一貫性のない状態になる可能性があります。彼はバスケットに行きます、そして、例えば、彼は命令を持っていません。彼は理由を理解しませんが、新しいバージョンではすべてのエラーが登録され、注文できない理由が明らかになります。

強制更新を支援するために、ソフト更新があります。これはGoogleのネイティブなものであり、アプリケーションに単に埋め込まれ、使用をブロックしません。しかし彼女は言う-Google Playにアップデートがあり、それをインストールすればあなたは新しいクールなものを手に入れるでしょう。

最初は、そのような対話によって実装されます。これはAndroidのネイティブデザインです。そして、それをアプリケーションに埋め込むことができます。たとえば、配色の「アプリケーションの更新」ウィジェットに実装しました。

Soft Updateを使用すると、バージョンの末尾を大幅に削減でき、ドキュメントに従って単純に実装されます。リリースが多い場合は、試してみてください。

もう1つの重要なツールは、機能切り替えです。ユーザー側の機能の一部を調整し、管理パネルで変更できます。追加のアプリケーション更新なしでサーバーからオン/オフできる一連の機能があります。

Feature Toggleがサードパーティアプリケーション（車両）の例でどのように機能するかについて話しましょう。当初、開発者はこのようなバイクを持っていますが、バイクにはすでに2つの機能トグルがあります。顧客が自転車を使用すると、テストチームは次のように言います。私たちはモーターをテストしました、モーターを動かし、運転し、冷却し、ユーザーのためにそれをオンにしましょう。

管理パネルに移動し、ユーザーを更新せずに機能切り替えと自転車をオンにすると、移動中にモペットになります。ユーザーは快適で、これにより彼はより速くより便利に動くことができます。

製品は開発中であり、聴衆は増加しており、もはや1つの原付には収まりません。ユーザーは家族を連れて行きたい、一緒に乗りたい。開発者と管理者は、追加の機能切り替え-大きなサイズを提供しています。管理パネルで有効にすると、外出先でユーザーの車両が大きくなります。

クールに見えます：Feature Toggleが役立ちます。これは事実ですが、発生する可能性のある問題があります。たとえば、下位互換性とFeature Toggle互換性を監視する必要があります。ある時点で、アプリケーションがモーターを壊し、クラッシュまたはバグが発生したとします。または、このモーターは多くのリソースを消費し、モーターで多くのユーザーをサポートすることはできません。次に、それをオフにする必要があります。

ただし、ユーザーのアプリケーションが消えないようにする必要があります。彼にはまだ大きなサイズのトグルがあるにもかかわらず、彼にアプリケーションを使用する機会を与えたいと思います。したがって、モーターをオフにすると、車両を制御するためのフォールバックメカニズムが必要になります。この場合、これはそのようなハイブリッドです。

おそらく、屋根がリクライニングすることを検討する価値がありました。おそらく、運転手はそのような座席に座るのに不快になるでしょう。しかし、彼は車を運転し、アプリケーションを使用し、歩くことはできません。

他にどのように機能切り替えを使用しますか？バックエンドがまだ開発中で、リリースの準備ができていないとします。次に、機能の一部を開発し、バックエンドとのすべての通信のAPIコントラクトをサポートし、UIをサポートし、機能トグルをオフにしてロールアウトします。バックエンドの準備ができたらすぐに、すべてが正常に機能することをテストし、機能する場合は機能切り替えを有効にします。その後、新しい機能を取得するためにユーザーを更新する必要はありません。つまり、すでにオーディエンスがあり、このオーディエンスにすぐに表示されます。とても素晴らしい。

今、すでに述べたように、AndroidとiOSの開発チームにはそれぞれ13人がいます。1つのGit Flow、1つのリポジトリーで作業し、計画されたリリースプロセスをセットアップして、市場投入までの時間を短縮し、毎週乗ります。最近、Huawei AppGalleryをリリースし、他のストアを調べました。機能切り替えにより、更新なしでユーザーアプリケーションを変更する方法を学びました。ご清聴ありがとうございました。

列車を解放します。Yandexレポート

Gitフロー

リリーストレイン

More articles: