DistributionチームのワークフローHandbook

共通リンク

• エンジニアリングチームワークフロー

まとめ

Distributionチームメンバーには以下が期待されます：

• コミュニティや他のチームとのやり取りで親切であること
• プロジェクトの赤いmainブランチの修正を最優先にすること
• プロジェクトのスケジュールキューから作業項目を選ぶこと
• 統合テストでカバーされていない変更のテスト計画を定義すること
• エンジニアリングメトリクスを追跡するためにIssueとマージリクエストにラベルを付けること

グループ

Distributionチームは2つのグループで構成されています：Distribution:BuildとDistribution:Deployです。

Distribution Buildのタスク

• すべてのDistributionプロジェクトのすべてのチームパイプラインを維持する
• 新しいクラウド、プラットフォーム、アーキテクチャ、コンポーネントのサポートに関するリサーチ
• アクセス制御、権限、CVEパッチ
• チームインフラ/リソース管理
• 依存関係の更新
• ライセンス管理
• バリデーション/認定のためのパートナーへの提出

Distribution Deployのタスク

• 初期インストールとコンポーザビリティ
• アップグレード/ダウングレード
• デプロイメントのスケーリング
• プラットフォームまたはプロバイダー間の移行
• データライフサイクル管理
• セキュアな設定とコミュニケーション
• 既存ツールとの統合のためのクラウドとプラットフォームのリサーチ

作業の優先順位付け

現在Distribution DRIとして機能していないDistributionチームメンバーが完了すべき作業の優先順位は以下のとおりです：

毎日何をするかを決めるための一般的なガイドとしてこの優先順位の概要を使用してください。このリストはチームマネージャーが設定したチームの全体的な優先事項と目標に向けて作業を向けるのに役立ちます。

ワークフローサマリー

Distributionグループは原則としてGitLab製品開発フローとラベルを使用しますが、作業の性質上、以下のフェーズは通常スキップします：

• バリデーションフェーズ4: デザイン
• バリデーションフェーズ5: ソリューションバリデーション

計画プロセス

すべての計画ダッシュボードは#g_distributionのIssue dashboardsフォルダーにブックマークされています。

四半期計画

四半期の3ヶ月目に：

1. PM & EM & スタッフエンジニア: 1週目までに、次の四半期のOKRsを下書きします。
2. OKR DRI: 2週目から、OKRを引き受けて他のチームメンバーまたはステークホルダーとスコープを開始します。
3. 全エンジニア: 2週目から、自分が興味を持つOKRスコープに貢献し始めます。
4. EM: 2週目末までに、スコープの現状に基づいて計画日の確保が必要かどうかを判断します。
5. 全員: 月末までに、OKRsとそのスコープを確定します。

マイルストーン計画

現在のマイルストーンの末に、すべてのエンジニアは アサインされたIssueを更新し、未完了のものをレビューのために次のマイルストーンにロールオーバーすることが 期待されます。

エンジニアリングマネージャーとプロダクトマネージャーは、Distributionチームの直接の責任である 作業のスケジューリングに責任があります。

未アサインのIssueは誰でも取り組むことができます。特定のタスクに取り組む意欲を示すには、 Issueにコメントを残します。コメントには作業を開始する日付を含める必要があります。 コメントに日付が含まれていない場合、または日付が過ぎた場合は、そのアイテムを誰でも 引き受けることができます。

現在のマイルストーンへのUnplanned作業の追加

緊急の対応が必要だが当初計画されていなかった作業が発生することがあります。誰でも合理的なものを 引き受けて作業できます。典型的なワークフローは以下のとおりです：

1. ベストジャッジメントで作業の緊急性を評価します。緊急性は通常、アクティブなインシデント、 内外のお客様への影響、SLAとポリシー、Deadlineによって判断できます。
2. 合理的なリクエストであれば、Unplannedとその他の必要なラベルをアサインし、 作業の優先順位付けに従って作業します。
3. そうでない場合は、リクエスターに理由を説明し、可能な代替案を提供し、 必要に応じてEM&PMにエスカレーションします。
4. 不明な場合は、リクエスターに明確化を求め、必要に応じてEM&PMにアドバイスを求めます。

バックログのレビュー

更新予定

必須ラベル

GitLab製品開発フローラベルに加えて、Epic、Issue、マージリクエスト（アイテム）にいつでも適用される いくつかの追加の必須ラベルがあります：

• group::distribution - Distributionチームに固有の、またはDistributionチームが作成したアイテム。スコープラベルであり、さらなるガイダンスが出るまでDistributionサブグループのすべてのアイテムに適用されます。
• group::distribution::* - Distributionサブグループの1つに固有の、またはそのサブグループが作成したアイテム。これらはネストされたスコープラベルであり、相互排他的ですが、group::distributionスコープラベルと共に使用できます。
  • group::distribution::build - buildグループに固有の、またはそのグループが作成したアイテム。
  • group::distribution::deploy - deploymentグループに固有の、またはそのグループが作成したアイテム。
• FY(2桁の年)::* (1-4) - 四半期内のリリースを目標とする努力を示すスコープラベル。例：FY24::Q2。

特定のシナリオ下で追加される追加の必須ラベルもあります：

• Unplanned - 現在のマイルストーンで当初計画されていなかった緊急リクエスト。これらのアイテムへの 作業は通常イベント駆動です。別のチームがサポートを必要としている、ユーザーに影響する回帰、 またはチームの非効率を引き起こしている技術的負債などです。
• spike - 主にオプションを理解し、将来の成果物を分解するためのリサーチを含むIssue。スパイクは、出力が追加のIssueと直列/並列作業の順序を定義する新しいEpicの最初のIssueであることがよくあります。

上記のラベルに加えて、マージリクエストレビュー中に使用されるワークフローラベルとIssueトリアージ中に使用されるラベルも参照してください。

優先度の定義

更新予定

Distribution DRI

チームメンバーの中断とコンテキストの切り替えを最小化するために、Distributionは週ごとのローテーションで1人のエンジニアをDRI（直接責任者）に指定し、通常の勤務時間中に以下の業務を担当します。それらの時間外の緊急リクエストは、オンコールプロセスで処理されます。

期待されること

DRIはリクエストの解決に単独で責任を持つわけではありません。適切な専門家（SME）を参加させ、必要に応じてエンジニアリングマネージャーおよび/またはプロダクトマネージャーにエスカレーションします。また、DRIが週中に同じ量のDeliverable作業を完了できるとは期待されません。特定の専門知識が必要なエスカレーションについては、Tier 2 On-Callプログラムを参照してください。

職務

Distribution DRIはリストの順序に従って以下のエリアに取り組みます。

週中

1. プロダクションからエスカレーションされたインシデントをサポートする。
2. お客様リクエストをサポートする
   • BuildとOperateのサポートヘルプリクエスト
3. #g_distribution Slackチャンネルの質問に回答またはリダイレクトする。
4. Issueトリアージを実施する。
5. GitLabでの@gitlab-org/distributionグループメンションに対応する。
6. オプション: 現在のマイルストーンのデリバラブルまたはその他のDistribution関連タスクに取り組む。

ハンドオーバー

1. アサインされたDRI Issueをクローズする。
2. シフトアサインリストの末尾に自分の名前をローテーションする。
3. リストの次のチームメンバーのために新しいIssueを作成してアサインする。IssueタイトルはDistribution DRI rotation week of <starting date>とします。説明を入力するためにDistribution-DRIテンプレートを使用してください。
4. ハンドオフ時にまだアクティブなリクエストについては、DRIはベストジャッジメントを使用して以下の1つまたは複数のオプションを検討します：
   • 文書化された緩和策でリクエストをクローズし、フォローアップIssueを作成する。
   • 翌週のDRIにリクエストを引き継ぐコメントを追加する。
   • SMEとして引き続き行動するが、知識を共有するための明確な文書と共に次のDRIへのハンドオフが強く推奨される。
   • 同期的な会話で次のDRIに情報を渡す。

その他のチームメンバー

DRI担当でない場合は、リクエストがStuff that should Just Workでない限り、以下を考慮してください：

1. アクティブなインシデントとデプロイメントブロッカーのリクエストを、通常勤務時間内はDistribution DRIにリダイレクトするか、最初に利用可能なチームメンバーとしてリクエストを引き受ける
2. SlackのDMをチャンネル#g_distributionにリダイレクトする
3. GitLabの直接メンションを@gitlab-org/distributionグループにリダイレクトする
4. その他のリクエストをDistributionとの連携方法にリダイレクトする

イテレーション

イテレーションを使用してスコープをより良くコントロールし、各リリースで測定可能な価値を提供します。タイムボックス測定プロセスにより、期待される進捗が達成されない場合に従うべき手順が確保されます。

• プロジェクトが定義されたMVC/Issue内で成功基準を達成せずに2マイルストーン以上続く場合は、詳細な評価/回顧が実施されます。
• プロジェクトが成功基準を満たさずに3マイルストーン続く場合は、セクションリーダーとのより大きな評価が実施されます。

目標はスコープの拡大を検出し、測定可能な価値を提供する方法でイテレーションし、必要に応じて早期に対応するためのサーキットブレーカーを設置することです。

Distributionの依存関係メンテナンスポリシー

Distributionチームはテクノロジービジョンを達成するために以下の依存関係メンテナンスポリシーに従います。

Distributionは、特に指定がない限り、元のリリースから3〜5マイルストーン以内にDistributionが管理する依存関係の新しいリリースのサポートを追加することを目指します。

Kubernetesリリースサポートポリシー

DistributionチームはKubernetesリリースのサポートに関してKubernetesリリースサポートポリシーに従います。

Distributionは、Kubernetesの新しいリリースから3ヶ月以内にサポートを追加することを目指します。

OS

GitLabがサポートするすべてのオペレーティングシステムとそのEOLポリシーは、サポートされているOSドキュメントページとインストールページに記載されています。

新しいOSリリースに対して、DistributionチームはLinuxパッケージサポートを以下のタイムラインで提供することを目指します：

採用面接

Distributionチームのポジションで面接を行うための情報については、hiring-processプロジェクトを参照してください。

ページのソースコードを見る - ページの編集 - please contribute.