共有機能・体験領域における協業

ステージ横断の機能コラボレーション

各ステージは、自身のビジョンや方向性を推進する機能を構築する責任を負います。たとえその機能の一部のコンポーネントが他のステージが通常所有する領域に踏み込むことがあっても、(そのステージにとって重要であれば) そのまま構築すべきです。

その機能が 前進するために必要、または緊急に必要なものではない 場合 (例えば、他の機能の開発をブロックしない場合)、その機能を所有するステージのバックログに入れることも常に検討できます。

「この作業はどのステージがやるべきか?」を考える際のガイドラインを以下に示します:

1. あるステージが自分たちにとって中核的な価値を持つ新機能を開発したい場合、たとえその機能が たまたま 別のステージが所有する機能の内部に存在することになっても、そのステージが構築すべきです。
2. 一方で、機能が別のステージの機能の内部に存在し、かつ 「あれば嬉しい」 程度のものである場合、Issue にして適切なラベルを付けることを検討しましょう。こうすることで、その機能を所有するステージが後日、適切なタイミングで優先順位付けできます。
3. 3rd-party システムとの統合に関する外部からの要求は、その統合の価値提案または影響を受ける領域に最も近いグループに振り向けます。

既存の統合のオーナーシップ

以下の表は、GitLab コードベースに存在する統合のオーナーシップを示しています。

セキュリティ関連の統合

CI/CD 統合

外部 Issue トラッカー

ソースコード統合

プロジェクト管理統合

認証統合

コンテナおよびパッケージ統合

検索統合

モバイル DevOps 統合

通知統合

その他の統合

DRI グループの責任

統合の DRI として指定された製品グループは、以下に責任を負います:

• ドメイン戦略に基づき、新しいコミュニティコントリビュート統合を GitLab コードベースに追加すべきかどうかを判断する
• ドメイン戦略に従って、既存の統合を GitLab コードベースに残すべきかどうかを判断する
• 必要に応じて統合を非推奨化・削除する適切なプロセスに従う
• 統合のドキュメントを保守する
• 統合関連の Issue を再アサイン・トリアージし、優先順位を判断する
• 目標 SLO の範囲内でバグとセキュリティ脆弱性を修正する
• infradev Issue に対処し、緊急の要求に応答する
• ヘルプの要求に応答し、統合を改善するイテレーションを行う

製品グループは、特定の統合をコミュニティサポートに指定し、コミュニティによる改善や追加機能の対象とすることも、各自の裁量で行えます。

このモデルにより、チームは柔軟に優先順位を調整でき、いずれのチームも「ブロック」されることがないようにしています。例外は、変更内容がソフトウェアエンジニアには許されていないこと (例えば本番環境の変更) を必要とする場合で、その場合はインフラストラクチャチームがブロッカーとなります。

どのチームもどのステージにも機能を貢献できますが、コントリビュートしているチームがそのグループの広範な計画とビジョンに整合できるよう、そのグループから最も関連するプロダクトマネージャーに連絡を取り、戦略的なサポートを得ることを推奨します。

以下は、他の製品グループがこれらの領域で作業する方法を理解し、その分野で支援してくれそうな最適な関係者を素早く見つけるためのガイドです。

このセクションは、エンジニアリングハンドブック版の 共有サービスとコンポーネントのオーナーシップ をモデルにしています。

既存のステージ横断機能

• マージリクエスト - 協業プロセス も参照
• CI/CD パイプラインをリポジトリ内で直接定義
• マイルストーンに紐づくリリース
• .gitlab-ci.yml からリリースを生成
• 脆弱性から GitLab または Jira Issue を作成
• Issue からマージリクエストを作成
• DORA メトリクスを通じた DevOps の成功の測定
• Issue タイプとしてのインシデントの作成
• CI/CD トンネル経由でクラスタに接続
• Issue と機能フラグの関連付け
• マルチプロジェクトパイプラインでの複数パイプラインの実行とプロジェクト依存関係
• Resource Groups でデプロイ中の同時実行制御を有効化
• ジョブアーティファクトまたは汎用パッケージをリリースに関連付ける

計画中のステージ横断改善

• Software Supply Chain Security

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