Software Supply Chain Security:Pipeline Security グループ

ビジョン

私たちはソフトウェアサプライチェーンプロセスにおけるセキュリティを提供し、パイプラインとジョブへの適切なレベルの可視性を確保します。これにより、組織は CI パイプラインを安全に運用できます。

私たちのチームは以下のカテゴリの提供に責任を持っています:

• シークレット管理
• アーティファクトセキュリティ

ミッション

私たちのミッションは、組織がセキュアなパイプライン運用を可能にする機能を、運用効率よく、大規模で高度なセキュリティを維持しながら提供することです。

パフォーマンス指標

私たちは プロダクトパフォーマンス指標 を使用して、貢献する価値を測定しています。PI プロセスの目標の一つは、プロダクトチームとして、将来の成功の先行指標となる主要指標を改善するための戦略的および運用上の改善に注力することを確保することです。

チームメンバー

以下の方々が Software Supply Chain Security:Pipeline Security グループの常設メンバーです:

チームメンバー情報は 原文 (英語) を参照してください。

安定したカウンターパート

安定したカウンターパートを確認するには、Pipeline Security プロダクトカテゴリリストをご覧ください。

JTBD

JTBD とジョブステートメントの現在のリストはこちらで確認・投稿できます。

テクノロジー

ほとんどの GitLab バックエンドチームと同様に、私たちはメイン GitLab アプリの Rails での作業に多くの時間を費やしています。Docker と Kubernetes の知識もチームで役立ちます。

共通リンク

• Issue トラッキングボード
• Issue バックログ
• Slack チャンネル
• グループ方向性ページ
• GitLab Unfiltered YouTube プレイリスト

リポジトリ

• GitLab

作業方法

計画

一般的な計画

私たちのチームはソフトウェアエンジニア in Test が割り当てられていないため、Quad-Planning プロセスを使用していません。代わりに、PM、EM、UX が協力して少なくとも3マイルストーン分の作業を高レベルで計画する「三脚（tripod）」アプローチを採用しています。計画中、PM はチームの全体的な方向性を設定し、EM と協力してチームの計画が野心的でありながら、チームのキャパシティに基づいて達成可能であることを確認します。これにより、計画の議論中のチェックアンドバランスが確保され、持ち越しを最小化し、ロードマップの機能優先事項とともにエンジニアリング優先事項が対処されます。UX は PM と協力して、実装に間に合うよう調査とデザイン Issue の準備を整えます。計画は主にリリース計画 Issue（以下参照）を通じて非同期で行われ、週次の 1:1 セッションやチームミーティングでの追加ディスカッションも行われます。この三脚アプローチにより、早い段階で依存関係に対処し、デザインとエンジニアリングがプロダクトロードマップで整合していることを確保できます。

リリース計画 Issue

私たちはリリース計画 Issue を使用して、各マイルストーンのリリースレベルの優先事項を計画します。この Issue は、成果物、キャパシティ、チームメンバーの休暇などを強調表示するために使用されます。これにより、チームメンバーとマネージャーは各リリースで何を達成する予定かを高レベルで確認でき、情報を収集する中央の場所として機能します。重要なのは、この計画 Issue はマイルストーン開始後は静的であり、マイルストーンへの変更（例: 優先度の高いアイテムがマイルストーム開始後に追加され、計画中の Issue が削除される）を反映するために更新されないことです。これにより、振り返り Issue の一部としてベースライン計画と最終リリースを比較できます。

Issue の重み付けとリファインメント

Issue を workflow::planning breakdown ステータスから workflow::ready for development ステータスに移動する前に、Issue に 0 より大きい重みを適用する必要があります。

私たちは2段階の見積もりプロセスを適用します:

• フェーズ1: 高レベル/概算見積もり。ここでの目的は、PM が複数マイルストーン先のキャパシティに従って Issue をスケジュールできるようにするため、EM が Issue に高レベルの推定重みを追加します。次に PM が Issue を特定のマイルストーンにスケジュールします。
• フェーズ2: リファインメント/検証済み見積もり。エンジニアは Issue のスケジュールされたマイルストーンの前の最初の2週間以内に推定重みを調整します（必要に応じて）。

この段階的なプロセスの目的は、アジャイルな計画を可能にし、各マイルストーン全体での Issue の調査とリファインメントに必要な頻繁なコンテキスト切り替えのエンジニアへの負担を軽減することです。さらに、これによりチームにグループの方向性についての四半期先見が提供されます。

リファインメントプロセス中に詳細な実装計画を作成する際の支援については、Issue リファインメント AI プロンプトを参照してください。

実装テンプレート

リファインメントプロセス（フェーズ2）では、一貫性と明確性を確保するため、Issue は GitLab Implementation Issue テンプレート を使用する必要があります。このテンプレートは以下を重視しています:

• なぜこの作業を行うのか: 解決しようとしている問題の明確な説明（「何を」と「なぜ」の両方を含む）
• 非機能要件: 必要に応じて、ドキュメント、フィーチャーフラグ、パフォーマンス、テストなどの詳細
• 実装計画: 詳細な技術的アプローチと実装ステップ
• 確認ステップ: 実装を確認するためのステップバイステップの指示

Issue をリファインメントする際、エンジニアは以下を実施してください:

1. Issue の説明に実装テンプレートの構造を使用する
2. 関連情報ですべてのセクションを完成させる
3. どのエンジニアでもアプローチを理解し、すぐに開発を開始できるほど詳細な情報を提供する
4. 情報の唯一の情報源として Issue の説明にすべての必要な情報を含める（コメントではなく）。コメントは必要に応じて追加のコンテキストに使用してください。

この標準化されたアプローチにより、明確性が向上し、リファインメント時間が短縮され、すべてのチームメンバーが実装 Issue に対して一貫した期待を持つことができます。

Issue 重みシステム

Issue の重みは、以下の基準の複雑さに基づいて決定されます:

• コード変更 — 必要なコード変更をどれほど難しく実施するか？
• 他チームとのインタラクションと依存関係 — 他チームとのインタラクションはどれほど必要か？
• 本番環境への道筋 — コード変更を安全に本番環境に投入するために何が必要か（例: フィーチャーフラグ、後方互換性など）？
• パフォーマンスへの影響 — システムの高パフォーマンスを維持するためには何が必要か？

これらの基準に基づき、Issue は以下のいずれかの重みを持つことができます:

1日以内に Issue の重みを決定できない場合は、詳細な調査のために別途調査 Issue を作成してください。

デザインと開発のコラボレーション

Issue にデザイン提案が必要な場合、私たちはプロダクト開発フローに従います。デザインと開発は最初から協力して、Issue が私たちの MVC ガイドラインに従っていることを確認しながら、価値と使いやすいエクスペリエンスを提供します。

SSOT を維持するため、デザインと開発には同じ Issue を使用する必要があります。これにより、両チームの重複した作業が減少します。プロダクトデザイナーは UX 完成の定義 テンプレートを使用して、Issue がプロダクト開発フローのどの段階にあるかを明確に示す必要があります。実践例は https://gitlab.com/gitlab-org/gitlab/-/issues/33418/ をご覧ください。

デザインが完成し、適切なワークフローラベルが適用されたら、デザイン、品質、開発（FE、BE、EM を含む）が協力して、必要に応じて実装のために Issue をさらに分解します。

技術的調査

リファインメントプロセスで、新機能にブループリントが必要であることが判明したり、メンテナーからの意見が問題のスコープ縮小、機能のパフォーマンス確保、または将来の技術的負債の軽減に役立つとチームが感じた場合、チームは調査のための技術的調査 Issue を作成します。この Issue は1人のチームメンバーに割り当てられます。そのチームメンバーは、理想的には5営業日以内に、問題へのアプローチを明確にするドキュメント、概念実証、またはその他の成果物を作成するための最低限の時間を費やす必要があります。これにより情報を収集し、他者と解決策を検証し、実行計画を提案できます。作業開始前に、技術的調査 Issue に概説された具体的な質問に回答します。このプロセスはスパイクの概念に類似しています。

可能であれば、割り当てられたチームメンバーは別の開発者と調査・結果の公開について同期セッションをスケジュールすることが奨励されます（技術的調査 Issue の例: gitlab#336617）。デフォルトでは技術的調査 Issue の重みは 2 で、開始からデータ提示まで3営業日でタイムボックスされています。チームメンバーは裁量でこの重みや期間を変更することができます。

各マイルストーンで割り当てる技術的調査 Issue の数を2件に制限して、全体的な速度と MR レート を維持します。

Issue の分割

Issue に複数のコンポーネント（例: ~frontend、~backend、~documentation）がある場合、別々の実装 Issue に分割する必要があります。これらの Issue を作成する際は、Frontend: [Issue タイトル] または Backend: [Issue タイトル] というタイトルを付け、一方が他方をブロックしている場合は blocked by とマークします。元の Issue は機能に関するすべてのディスカッションを保持し、実装 Issue は行われた作業の追跡に使用します。Issue を分割することで、いくつかのメリットがあります:

1. Issue ごとに DRI が1人だけになります。
2. ワークフローラベルとヘルスステータスがより関連性を持ちます。
3. Issue をより正確に重み付けできます。
4. 一方の実装を他方のブロッカーとしてマークできます。
5. 各機能グループがどの作業を取り上げられるかが分かりやすくなります。
6. 複数のマイルストーンにわたって機能作業をスケジュールできます。
7. チームメンバーがグループワークフローボードから作業を選択する際に、どの Issue がどのコンポーネントに関連するかが簡略化されます。

エラーバジェット Issue

ステージグループのエラーバジェットは、顧客とインフラのパフォーマンスに影響を与えている Issue をグループが特定して優先順位付けするために確立されています。

Pipeline Security グループのエラーバジェットダッシュボードは、Pipeline Security グループのエラーバジェット消費に貢献している Issue を特定するために使用されます。

エンジニアリングマネージャーは、予算を超過しているかどうかを判断し、エラーバジェット消費に貢献しているものがあれば特定し、プロダクトマネージャーの優先順位付けのために根本原因に対処する Issue を作成するために、週次でエラーバジェットダッシュボードを確認します。エラーバジェット消費に対処するために作成された Issue は、適切なラベルを使用して作成し、技術的負債プロセスに従って優先順位付けする必要があります。

技術的負債と延期 UX の優先順位付け

私たちは技術的負債と延期 UX の優先順位付けについて、会社のガイダンスに従います。これを効果的に管理するため、「~workflow::scheduling」列で、作業準備ができている技術的負債、延期 UX、機能メンテナンス Issue をプロダクトによって優先順位付けして追跡します。これらの Issue が将来の速度に与える影響によって告知されます。各マイルストーンの重みによる能力の一定割合（〜30%）を技術的負債と延期 UX の解消に費やすよう努めます。バグは負債とは見なさず、残りの能力による重みの一部として優先順位付けされます。

マイルストーン内の成果物

エンジニアリングマネージャーは、以下の基準を満たす Issue に Deliverable ラベルを適用します:

• ユーザーに見える価値を提供する
• Issue ボードの上位近くにある（高優先度）
• Issue が明確に定義されている
• UX DoD が適用されている
• Issue に重みが付けられている
• エンジニアリングマネージャーが割り当てられたマイルストーン内で作業を完了するキャパシティがあると確信している
• チームが Issue をマイルストーンに受け入れ、~“workflow::ready for development” ステータスに移動した

準備完了の定義

チームがマイルストーンに Issue を作業として受け入れるには、以下の基準を満たす必要があります:

• ~“type::feature” とラベル付けされた Issue には、明確に述べられた「なぜ」と顧客の問題が含まれている
• ~“type::bug” とラベル付けされた Issue には再現手順が含まれている
• 必要であればデザインタブにデザインがある
• Issue が Software Supply Chain Security:Pipeline Security エンジニアによって作業される場合、重み が付けられている
• デザイン提案が UX 完成の定義（DoD） を満たしている

ブロック状態の定義

Canary 上での検証のために別の Issue の完了を待つ必要がある Issue はブロック状態とみなされ、~workflow::blocked ラベルを適用する必要があります。Issue はまた、Issue の関連 Issue セクションでブロック状態としてマークする必要があります。

フォローアップ Issue

私たちは、同じマイルストーム内で作成され作業される別の Issue のフォローアップとなる Issue に ~follow-up ラベルを追加するプロセスを採用しています。チームが作成して ~follow-up とラベル付けする可能性があるアイテムの例には、機能のスコープクリープ、コードレビューからの非ブロッキングリクエスト、追加の UI ポリッシュ、非ブロッキングのリファクタリング、低優先度（P2 以下）のバグ修正などが含まれますが、これらに限りません。

リリースポストチェックリスト Issue

各マイルストーム中に、チームのリリースポストの進捗を追跡するためにチームメンバーが使用するリリースポストチェックリスト Issue を作成します。チェックリスト Issue は、リリースポストのマージリクエストと実装 Issue へのリンク、更新されたドキュメントへのリンク、各 Issue に取り組んでいるエンジニアのリストを関連付けるために使用します。チェックリスト Issue は、すべての情報を一箇所で確認できる場所を提供します。

ワークフロー

以下で特別に言及されない限り、Software Supply Chain Security:Pipeline Security グループは標準のエンジニアリング、プロダクト、UX ワークフローに従います。

新しい作業の開始

Software Supply Chain Security:Pipeline Security チームメンバーは、マイルストーンボードの**右から左に**向かって作業を探し始めることが奨励されています。これは「右から引く」としても知られています。ボード上でチームメンバーが助けられる Issue がある場合、新しい作業を始める代わりにそうすべきです。これには、チームメンバーが割り当てられていない Issue のコードレビューを実施することも含まれます（価値を追加して Issue を前進させることができると感じる場合）。

具体的には、以下の順序で行います:

• コードがステージング、カナリア、または本番環境に到達したことの確認
• workflow::in review の Issue に関するコードレビューの実施
• workflow::in development 列の誰かのブロック解除
• 最後に、workflow::ready for development 列から Deliverable を取り上げる

このプロセスの目標は WIP を削減することです。WIP の削減により「より少なく始め、より多く終わらせる」ことを強制し、サイクルタイムも削減されます。エンジニアは、マージリクエストの DRI は作成者であることを念頭に置く必要があります。チームワークの重要性を強調しても、DRI を持つことが私たちの価値観で奨励されているという事実を薄めるべきではありません。

取り上げられる Deliverable Issue がなくなった場合の対処法

チームメンバーが「右から引く」ことができる Deliverable Issue がなくなった場合、以下のいずれかを実施できます:

• workflow::ready for development と SSCS::P2 ラベルが付いた Issue を取り上げる。
• workflow::planning breakdown と needs weight ラベルが付いた Issue をリファインメントして、今後のマイルストーンの準備をする。
• 関心のある技術的負債や低リスクの Issue に取り組む機会とする。これらの Issue はしばしば Deliverable として計画するほど高い優先度がないため、エンジニアはキャパシティがあるときにこれらの Issue に積極的に取り組むことが奨励されます。

優先度

私たちはマイルストーン内の最高優先度 Issue を示すためにラベルのシリーズを使用しています。

• 特定のマイルストームの最高優先度は Deliverable と SSCS::P1 ラベルが付いた Issue です。
• bug::vulnerability ラベルが付いた Deliverable Issue がある場合、それらは他の Deliverable より最高優先度とする必要があります。
• SSCS::P2 と SSCS::P3 ラベルは将来のマイルストームの Deliverable として計画された Issue の優先順位付けに使用します。

チームメンバーが特定の Issue を Deliverable またはより高い優先度と見なすべきだと思う場合、議論・決定できる Issue でプロダクトマネージャーとエンジニアリングマネージャーに ping することが奨励されます。Issue は Deliverable ラベルの候補とみなされるために重みを付けてリファインメントされている必要があることに注意してください。

コードレビュー

コードレビューは、レビュアーとメンテナーを選択するためにレビュアールーレットを使用する標準プロセスに従います。ルーレットはオプションであり、マージリクエストにグループ外の人が深く理解できない可能性がある変更が含まれている場合、問題を正しく解決することに焦点を当てるために、Software Supply Chain Security:Pipeline Security チームのメンバーを予備レビューに選択することが奨励されます。この選択はエンジニアの裁量に委ねられますが、Software Supply Chain Security:Pipeline Security チームの仲間のメンバーが私たちが実装している機能の意味を最もよく理解できる場合があるという考えを提起します。その後、メンテナーレビューは品質とコード標準により焦点を当てます。

また、GitLab コードレビュープロセスで説明されているように、割り当てられていない場合でも、チームメンバーが互いのマージリクエストをレビューする時間を取ることをお勧めします。マージリクエストに最初のドメインレビュアー以外の誰かを割り当てる必要はありません。このプロセスの補完は、割り当てられていないマージリクエストをレビューするためにチームメンバーを奨励することを目的としています。新しいチームとして、互いのマージリクエストをレビューすることで、私たちのプロダクト領域への親しみを築き、機能や修正の実装時に必要な調査量を減らし、ロッタリーファクターを高めます。私たち自身でできるレビューが多いほど、メンテナーがマージリクエストを良い状態にするための作業が少なくなります。

この戦術はまた、WIP マージリクエストに対して早期レビューを求める環境を作り、解決策がコラボレーションを通じてより洗練される可能性があり、チーム全体での知識共有も促進します。

UX レビュー

コードレビュープロセスの一環として、MR がユーザー向けの変更を行う場合（どんなに小さくても）、プロダクトデザイナーによるレビューが必要です。MR が ~UX ラベルを持つ Issue に関連している場合は、プロダクトデザイナーを参加させてください。レビュープロセスを全員にとって容易にするため、可能な限り MR の説明にスクリーンショットや画面録画を含めてください。

フィーチャーフラグの背後にある機能の反復については、変更がすぐにユーザー向けにならない場合でも、プロダクトデザイナーを参加させてください。プロダクトデザイナーが効率的と判断した場合、機能フラグが付いた機能のレビューを完成に近づくまで延期することを選択することができます。このオプションにより、ワークロードを柔軟に優先順位付けし、MR レビュープロセスによって生じるノイズの一部を避けることができます。

Issue ヘルスステータスの定義

• 順調（On Track） — 現在のマイルストームでこの Issue が完了してライブになることを確信しています。ここからは下り坂です。
• 要注意（Needs Attention） — 放置すると Issue が目標リリースに間に合わなくなる懸念、新たな複雑さ、または未解決の質問があります。週内に 順調 に戻るためのコラボレーションが必要です。
  • アイテムをこのステータスに移動する場合は、アイテムが 順調 ステータスに戻れるよう役立てると思われる Issue 内の個人に言及してください。
• 危険（At Risk） — Issue は現在の状態では計画されたリリースに間に合わず、順調 に戻すために即時の対応が必要です。
  • アイテムをこのステータスに移動する場合は、Slack の#g_pipeline-security チャンネルへの投稿を検討してください。メッセージには、アイテムが 順調 ステータスに戻るために実施できることを含めるようにしてください。
  • 注意: 現在のマイルストームでアイテムを順調に戻せることが何もない場合があります。その場合は、気づいた時点でできるだけ早くマネージャーに知らせてください。

Issue 進捗更新

エンジニアが Issue を積極的に作業している場合（~workflow::“In dev” またはそれより右側の現在のマイルストームワークフロー）、または割り当てられた Issue に共有すべき重要な詳細がある場合、週末のサマリーを提供するためにトップレベルのコメントとしてステータス更新を残します。

ステータスコメントには以下を含める必要があります:

• 更新されたヘルスステータス
• ブロッカー
• 達成したことに関するメモ
• レビューが開始されているかどうか
• エンジニアが有益と感じるその他の情報
• EM を更新に cc する

複数の人が Issue に取り組んでいる場合は、これがフロントエンドかバックエンドの更新かも含めてください。Issue に関連する各 MR の更新は更新コメントに含める必要があります。エンジニアはこの時点で Issue のヘルスステータスも更新する必要があります。

この更新は特定のフォーマットに従う必要はありません。フォーマットのアイデア:

Health status: (On track|Needs attention|At risk)
Notes: (Issue が注意が必要または危険な場合に特に共有が必要な内容)

Health status: (On track|Needs attention|At risk)
What's left to be done:
What's blocking: (順調な場合はおそらく空)

## Update <date>
Health status: (On track|Needs attention|At risk)
What's left to be done:

#### MRs
1. !MyMR1
1. !MyMR2
1. !MyMR3

このアプローチにはいくつかのメリットがあります:

• チームメンバーは Issue をボード上で前進させるために何ができるかをより適切に特定できます
• 他のエンジニアがアイデアがある場合に参加してコラボレーションする機会を作ります
• ステータス更新を残すことは、質問をして議論を始める良いきっかけになります
• GitLab のより広いコミュニティがプロダクト開発をより容易に追跡できます
• Issue が遭遇した障害の歴史が振り返りのためにすぐに利用可能です
• プロダクトマネージャーとエンジニアリングマネージャーは作業の進捗をより簡単に把握できます

いくつかのメモ/提案:

• 私たちは通常、エンジニアが特別な状況を除いて週に少なくとも1回のステータス更新を残すことを期待します
• 理想的には、ステータス更新はエンジニアのワークフローの論理的な部分で行われ、中断を最小化します
• 更新は毎週同じ時間/曜日に行う必要はありません
• 一般的に、更新を残す論理的な時間がある場合、それが最適な時間です
• エンジニアはこれらの更新を、Issue を解決しながら技術的なメモや考えを収集したり「声に出して考える」場所として使うことが奨励されます

フィーチャーフラグの背後にある変更の監視

GitLab でのフィーチャーフラグを使用した開発に文書化された手順に加えて、Software Supply Chain Security:Pipeline Security エンジニアは、可能な場合はダッシュボードとログを使用して変更のインフラへの影響を監視します。フィーチャーフラグによりエンジニアが本番環境でのコードを完全に制御できるため、変更が本番インフラに与える影響の監視の責任を取ることも可能になります。変更を監視するために、この役立つダッシュボードの選択、特に本番環境での変更を監視するための Rails コントローラーダッシュボード（内部のみ）を使用しています。評価するメトリクスには、変更の予想される影響と Issue で言及された考慮事項に応じて、レイテンシ、スループット、CPU 使用率、メモリ使用率、データベースコールが含まれます。

このプロセスの目標は、変更が本番インフラに与える可能性のある時間を最小限に抑えることです。このプロセスの副次的なメリットは、監視ツールへのエンジニアの親しみを高め、インフラメトリクスに関連した変更の結果を予測する経験を積むことです。

Issue のクローズ

エンジニアが Issue の完成の定義が満たされていることを確認した後、Issue をクローズする責任を持ちます。Issue が完了したことを確認する責任があるエンジニアは、その Issue の DRI、または Issue の作業を完成させる最終マージリクエストの DRI です。

コミュニティ貢献のための Issue

私たちは、コード、ドキュメント、UX、その他を問わず、GitLab への貢献に興味を持つすべての人に対して歓迎的な環境を作りたいと考えています。

コミュニティコントリビューターによって作成されたマージリクエストで Issue が解決されている場合、エンジニアリングマネージャーが関連する Issue を自身に割り当てて、より良く追跡します。エンジニアリングマネージャーはコミュニティコントリビューターにマージリクエストプロセスを通じてコーチングを行うか、チームメンバーエンジニアにそのコーチングを委任する責任を負います。

ラベル

カテゴリラベル

Pipeline Security グループは以下に記載されているプロダクトマーケティングカテゴリをサポートしています:

機能ラベル

ミーティング

Pipeline Security グループ週次ミーティング

この同期ミーティングは、過去1週間でブロックされている事項や注目すべき事項について話し合うためのものです。このミーティングはチームのタッチポイントとして機能します。このミーティングは週に2セッション行います — APAC/EMEA タイムゾーン向けと AMER タイムゾーン向けです。すべての人が非同期でディスカッションの恩恵を受けられるよう、各ミーティングを録画します。

非同期スタンドアップ

非同期スタンドアップには Slack と統合された geekbot を使用します。スタンドアップの目的は、全員が何に取り組んでいるかをチームに知らせ、ブロッカーを表面化して解消することです。スタンドアップボットは火曜日と金曜日のチームメンバーの現地時間の午前10時に実行され、3つの質問をします:

1. 前回の更新から何をしましたか？
2. 現在何に取り組んでいますか？
3. 進捗を妨げているものはありますか？

週次ベースで、チームメンバーは現在のマイルストームに割り当てられた Issue の簡単な更新を共有します。 更新は、Issue 進捗更新ガイドラインに従ってコメントの形で Issue で共有されます。 エンジニアリングマネージャーが翌月曜日にグループの週次更新を公開できるよう、 金曜日（または週の最後の作業日）に投稿する必要があります。

非同期月次振り返り

月次振り返りにはこのプロジェクトの GitLab Issue を使用します。Issue は現在のマイルストームの終わり近くに自動的に作成されます。月次振り返り Issue の目的は、マイルストームを振り返り、うまくいったこと、うまくいかなかったこと、改善できることについて話し合うことです。 振り返り Issue に月末まで待って項目を追加するのではなく、チームメンバーが月を通じてコメントを追加することを奨励します。毎週金曜日に #g_pipeline-security チャンネルに Slack リマインダーがあり、Issue に項目を追加するよう促します。

振り返りコメントの分析とアクションアイテムの抽出に関する支援については、振り返りサマリー AI プロンプトを参照してください。

私たちとの協力方法

Issue について

Pipeline Security グループが取り組む Issue には ~"group::pipeline security" のグループラベルが付いています。DevOps ツールチェーンの SSCS ステージに貢献する Issue には ~"devops::software supply chain security" ラベルが付いています。

特定の人に対応する場合は Issue で @mention でタグ付けできます。グループ全体の注意を引く必要がある場合は、チーム全体に通知する @gitlab-com/pipeline-security-group をタグ付けできます。

AI プロンプト

私たちは GitLab Duo で使用するために設計された AI プロンプトのコレクションを維持しており、日常的なタスクの支援に活用しています。これらのプロンプトはチームの特定のワークフローとプロセスに合わせています。

• Pipeline Security グループの AI プロンプト

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