リリース管理について知っておくべきことすべて

絶えず変化し進化するアプリの世界では、中途半端なリリースをユーザーに提供することはできません。ここでリリース管理が役立ちます。Hikeのマネージャーの1人からのこの資料は、列車のリリースと分岐戦略について説明し、専門分野を拡大してプロジェクト管理の理解を得ようとしている人々を最新のものにします。

---

リリース管理とは何ですか？

リリース管理は、開発とテストから展開まで、ソフトウェアリリースのすべてのフェーズをカバーします。新しい製品が要求されるたび、または既存の製品に変更を加えるたびに、リリース管理が必要になります。この状況で実行する5つの基本的なリリース管理手順があります。

1. リリース計画
   
   
2. リリースビルド
   
   
3. 受け入れユーザーテスト
   
   
4. リリース準備
   
   
5. リリースをデプロイします。
   
   

リリース計画

リリース全体が最初から最後まで編成されるのはこの段階であるため、計画フェーズはほとんどの場合集中的です。堅実なリリース計画は、順調に進み、標準と要件が適切に遵守されていることを確認するのに役立ちます。



リリースを計画するとき、複数のチームによって開発されたアプリケーションには、事前にリリースする必要がある一貫したアプローチが必要であると考えています。ここで「トレインリリース」の概念が役立ちます。トレインリリースアプローチに従うことで、チームはリリースに基づいて変更をスケジュールし、Playストアに送信できます。



トレインリリースの実装を開始する前であっても、最初のステップは、各ステージの時間間隔を定義することです。私たちの場合、開発段階は2週間です。次に、統合テストと展開の手順に費やす時間を決定する必要があります。以下は、間隔の例です。

1. クリッピング：1日目から始まります。
2. アルファ/ UATバージョンの内部テスト：3日。
3. 段階的展開[1％]レビューのための提出。
4. レビュー期間：3日。
5. ある日、ユーザーの20％。
6. ある日、ユーザーの50％で、同じ日にユーザーの100％に成長します。

上記の例に基づくと、アプリケーションの新しいバージョンが一般に利用可能になるまで、合計10日かかります。







リリースに向けた次のステップは、チームと主要な利害関係者の両方がリリース全体で参照できるワークフローを作成することです。



ワークフローでは、リリース全体がどのように機能し、各チームメンバーがどのような役割を果たしているかがすぐに説明されます。Asanaツールを使用して、以下に示すようにこれらの詳細を表示します。

• タイミング
• 推定配達時間
• 要件
• プロジェクトの全体的な規模

計画を作成した後、すべての利害関係者（リリースグループ、製品マネージャー、およびハイレベルリーダー）に提出して検討します。次に、要件やアプリケーションで見られるギャップや問題についてフィードバックを受け取ります。







計画が承認されて確定すると、楽しみが始まります！

リリース計画の重要な側面

トレインリリースの作成と使用は素晴らしいように聞こえますが、トレインリリースの計画中にプロセスを稼働させ続けるのは難しい場合があります。このプロセスの詳細は次のとおりです。

• リリースマネージャは、リリースを管理および調整します。
• レビューおよびテスト済みのコードのみを受け付けます。
• プロセスには実装段階があります。
• リリースされたバージョンのアプリケーションを監視しています。

建物を解放する

リリース計画の準備ができたら、製品のリリーステストを開始できます。これは、リリース計画で概説されている要件に基づいた、製品の実際の「ユーザーレベルのテスト」になります。



特定の日時（たとえば、月曜日の15:00）に、コードがフリーズ/クリップされます。この時点まで、チームは機能を調べ、テストし、開発ブランチにマージする時間があります。開発ブランチは、トレインリリースの一部である必要があります。15:00に、リリースマネージャーは開発ブランチからリリースブランチを作成します。このステップはJenkinsで自動化されています。



ブランチの移行を自動化することにより、すべてのパフォーマンスのしきい値を確認し、以前のリリースから市場へのベンチマークと自動化が比較の基準として現在のものに設定され、列車のリリースがそれ以上の変更からブロックされます。







コードがフリーズすると、新しい開発サイクルが始まり、参加しているすべてのチームが新しいスプリントを開始して開発を続けます。列車のリリースの素晴らしいところは、誰もが次の計画されたリリースについて知っていることであり、それは人々がそれに応じて仕事を計画するのに役立ちます。

ブランチリリースとバージョンコントロール

通常、製品開発はリリースの開発が終了しても停止しないため、最初に考えるのは、テスト対象のビルドをフリーズすると同時に、次のリリースの新機能に取り組む方法です。リリースビルドにエラーが表示された場合はどうなりますか？エラーが見つかる前にすでにたくさんの新しいものを追加している場合、エラーを修正するにはどうすればよいですか？







ここで、分岐の概念を持つ巧妙な分岐戦略が登場します。名前が示すように、分岐コードとは、木の枝と同じように、分岐のコードが特定のポイントまで一致し、2つのコピーに分割されることを意味します。



各ブランチは、互いに独立して開発できます。この場合、1つのコピー（リリースブランチ）は、中断したところからフリーズしたままになります。これは、クリップされたブランチと呼ばれるものです。別のブランチ（開発ブランチ）は、リリースブランチにまったく影響を与えることなく、新しいコードとバグ修正で変更できます。リリース候補にバグが見つかった場合は、修正を開発してリリースブランチに追加できます。したがって、リリースブランチから再度ビルドする次のビルドは、1つのバグ修正を除いて、最初のビルドと同じである可能性があります。このようにして、リリース内の新しいバグのリスクを最小限に抑え、新しいコードからバグを分離できます。同じバグが次のリリースに反映されないように、開発ブランチにも修正が適用されます。リリースブランチのもう1つの利点は、実際にコードを公開すると、公開されたコードベースの正確なコピーである「フリーズ」ブランチが作成されることです。いつでもこのコードに戻って参照できます。

ユーザー受け入れテスト

収集されるデータの量と、ビルドを正式に起動するために必要なものにするために必要な修正があるため、ユーザー受け入れテストはリリース管理にとって最も重要なステップです。







名前が示すように、このタイプのテストに関しては、重要なのはユーザーです。ユーザーは、まさにアプリケーションを使用する人です。したがって、ユーザーをソフトウェア開発プロセスの全体的な品質保証戦略の一部にすることが不可欠です。ここでUATが役に立ちます。このタイプのテストは、他に類を見ないものであり、ユーザーのニーズを製品開発の中心に置きます。このようなテストが答えようとする質問のいくつかを次に示します。

• ユーザーはアプリを操作できますか？
• アプリケーションは期待どおりに動作しますか？
• アプリはユーザーの問題を解決しますか？

効果的なUAT（User Acceptance Testing）がないと、開発中のプロジェクトが成功する可能性が大幅に低下します。これが、カスタムが配信プロセスの非常に重要な部分である理由です。前述のように、UATは反復プロセスの一部です。エラーが特定されると、チームはエラーを修正するために戻ってきます。バグはリリースブランチで修正されてから、開発ブランチにマージされます。ビルドは、最終的な実装とリリースについて調べることができるように、UATステージを通過する必要があります。



上級者向けのヒント：UAT計画には常に内部テストを含めてください。



UATリリースをスピードアップする1つの方法は、Googleが提供する内部テストトラックを使用することでした。これにより、JIRAチケットを自動的に生成することで、同僚にチケットをすばやく配布し、フィードバックを収集することができます。チームはまた、最終テストを提出する前にフィードバックが考慮されることを確認します。

準備とリリース

このステップは、UATで理解されたすべてのことを考慮に入れて、製品の仕上げを行うことです。リリースの準備には、QCチームによる最終的な品質チェックも含まれます。検査中、QAチームは最終チェックを実施して、アセンブリがリリース計画の最小許容基準とビジネス要件を満たしていることを確認します。



レビューが完了すると、リリースグループはリリースを完了して展開を開始します。アセンブリをライブ環境に展開する前に、設計チームなどの関連する責任チームによる承認が必要です。UATは、次のステージに渡される前に結果が検証されることを保証します。

リリースのデプロイ

最後に、私たちのチームのすべての努力が報われた大きな日が来ました。私たちの製品を生産のために野生にリリースする時が来ました。アセンブリを実稼働環境に送信するだけでなく、実装フェーズには、エンドユーザーと企業全体の両方を対象とした製品の操作方法に関するトレーニングも含まれます。たとえば、リリースの変更についてユーザーに通知する必要があります。この場合、「新着情報」は視野に表示されません。次の手順を含む自動化されたJenkinsプロセスがあります。

• 最終アセンブリの作成[ブランチとバージョン名を指定]。
• 「新機能」がリリースに追加されました。
• 展開率の追加。
• 各ステージには、各コマンド[UAT、ベンチマーク、パフォーマンス、自動化]からの信号（赤/緑）の手動入力があります。

シグナルがビルドを許可するとすぐに、ビルドは定義された展開パーセンテージでPlayストアに自動的にアップロードされます。バージョンタグのコミットと設定、アセンブリのDropboxへの保存、適切なSlackチャネルへの公開と更新の内部手順も、同じパイプラインを介して実行されます。







この場合、1％まで展開することから始めます。考えられる問題を特定するために、各段階でレビューをフォローする必要があります。また、リリースフォールを監視するためのツールも必要です。



エラーが1％で目立つようになった場合、チームは問題に対応し、問題を迅速に修正するかどうかを決定する機会があります。もしそうなら、列車のリリースは5％の次の展開ステップに到達しないはずです。代わりに、問題はユーザーの1％で解決されます。問題が修正され、解決策が確認されると、列車の解放は5％の段階に進むことができます。



トレインリリースのシンプルバージョンと同様に、コードがフリーズされた後は、リリースエンジニアまたはリリースチームのみがリリースプロセスを処理します。他のすべてのチームは「通常の」開発を続けます。

リリース後の分析

コードが公開されてもリリース管理作業は終了せず、リリースを再度リリースする準備ができるまで続行されます。アプリを成功させるには、適切なレビューが必要です。また、本番環境のリリースに従ってバグを修正し、ユーザーが必要とする機能を実装し、ユーザーの問題を解決する必要があります。これを行うには、Firebase Crashlyticsを使用します。ここでは、即時の修正が必要なクラッシュを追跡します。



さらに、アプリのレビューは、他のアプローチでは取得がはるかに難しい製品への洞察を提供します。GooglePlayとAppStoreはどちらも、アプリ開発者にレビューに返信する機能を提供します。これは、ユーザーからアプリの問題について詳しく知るための非常に便利なツールです。証言は、ユーザーがアプリで経験している問題を特定し、将来の変更について通知することができます。

まとめましょう

リリース管理は、非常に動的なプロセスを監視します。各リリースは、ワークフローからチェックリストまで、改善の余地がある領域を見つけて、すべてを改善する機会です。これが私たちが得た利点のいくつかです：

• コミュニケーションと調整を改善することにより、生産性を向上させました。
• 当社のリリースはより迅速に配信されるため、リスクも軽減されます。これらの変更には、高品質のリリースを定期的に高速で配信できるチームが関与します。
• リリース管理は、開発および運用方法の体系化と最適化もサポートします。

また、リリース管理プロセスにより、開発者や製品の所有者から経営幹部に至るまで、すべての人が高レベルの計画を確認し、進捗状況のスナップショットを取得して同期して作業することが容易になりました。

• DevOpsコース
• データサイエンスの職業訓練
• データアナリストトレーニング
• Python forWeb開発コース