リリース/フィーチャー決定ワークフロー
このドキュメントでは、リリースブログ投稿への掲載を目的として、機能がマイルストーンリリースに含まれるかどうかを決定するためのワークフローを説明します。
リリース/フィーチャー決定ワークフロー
各リリースポストは、PM が投稿のさまざまなセクションを説明するために作成した多くの MR で構成されています。これらの MR がレビューされ公開準備が整うと、関連するエンジニアリングマネージャーにアサインされ、このプロセスが始まります。例: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/32608
手動プロセス
場合によっては自動化がステータスを決定できないことがあり、その場合は以下に説明する手動プロセスを使用してください。
ステップ 1: 関連する Issue を見つける
これらの MR には、更新を説明する1つ以上の yaml ファイルが含まれています。EM はこれらの yaml ファイルをレビューして、機能がリリースに含まれているかどうかを判断する必要があります。そのためには、MR の変更を確認し、yaml ファイルで参照されている issue_url を見つけてください。それがリリースポスト MR で説明されている機能を指しています。
ステップ 2: 関連する MR を見つける
関連する Issue ページから、その Issue の関連 MR を確認します。現在のマイルストーンにアサインされているすべての関連 MR がマージされていれば、リリースに含まれます。現在のマイルストーンにアサインされていてまだマージされていない MR がある場合は、機能が完成していないと判断されます。
現在のマイルストーンにアサインされているすべての関連 MR がマージされている場合、次のステップはそれらの MR がデプロイされてプロダクション環境で稼働しているかどうかを確認することです。これはマージコミットの SHA を使用して chatops にクエリすることで行えます。
すべての chatops クエリが SHA が現在プロダクション環境で稼働していることを示すステータスを返した場合、機能が完成していると判断されます。
これらのクエリの1つ以上がプロダクション環境で稼働していないことを示すステータスを返した場合、機能が完成していないと判断されます。
ステップ 3: リリースポスト MR を更新する
機能が完成していると判断された場合、EM はリリースポスト MR をマージして変更がリリースポストに含まれるようにします。
機能が完成していない場合、EM はリリースポスト MR のマイルストーンを次のリリースのマイルストーンに更新します。
タイムライン
リリースポスト MR は毎月 17 日までにマージされる必要があります。そのタイムラインに対応するため、EM はリリースポスト MR が準備できたらすぐに評価し、可能であれば早めにマージしてください。17 日以降、マージされていないリリースポスト MR は次のマイルストーンに移行されます。
バグとパフォーマンス強化
リリースポストマネージャーが作成したオープンな MR にコミットすることで、バグ修正とパフォーマンス改善がリリースポストに含まれるようにしてください。
