Verify:Pipeline Authoring グループ

有用なリンク

プロダクト

• プロダクトビジョン
• Pipeline Authoring カテゴリの方向性
• ci_pipelines をトリガーするユニークユーザー数（パフォーマンス指標） - 内部リンク
• CI/CD 開発ドキュメント
• CI/CD コンポーネントドキュメント
• CI/CD カタログドキュメント

チームハンドル

チームリソース

• チームリソース
• ワークフローボード: ~group::pipeline authoring

動画

• GitLab Unfiltered: Pipeline Execution グループ（CI 関連）
• CI バックエンドアーキテクチャウォークスルー - 2020 年 5 月
• フロントエンド CI プロダクト / コードベース概要 - 2020 年 6 月
• CI/CD カタログデモ

コアドメイン

プロダクト

機能

• パイプライン作成
• YAML 構文
• CI/CD 設定リントツール
• CI/CD 変数
• 追加機能はこちら

テクニカルロードマップ

FY25 の残り

これらは FY25 の残りにおける私たちの高レベルなエンジニアリング主導の目標です。意欲的であり変更される可能性がありますが、これらの領域でどこに注力するかを示しています。

パフォーマンスとコスト削減

パイプライン作成速度

注意: パイプライン作成フィードバック Issue。パイプライン作成プロセスでの体験についてのご意見をお待ちしています。

目標:

• パイプライン作成サービスのコンポーネントを理解して速度を向上させます。
  • このグラフはパイプライン作成パフォーマンスに関するデータをキャプチャしています。
• パイプライン作成パフォーマンスの最適化に関して特定されたトップ 3 の Issue:
  • パイプライン作成時に Sidekiq ジョブを一括挿入
  • CI 変数を遅延かつ選択的に展開
  • 並列ジョブのルールを一度だけ評価

効率性

目標:

• データ構造検証のためにエントリクラスから JSON スキーマへ移行します。- Issue

可視性

CI カタログのインストルメンテーション

目標:

• インストルメンテーションを追加して CI/CD カタログの使用状況の可視性を高めるために特定されたトップ 3 の Issue:
  • GraphQL コール時間のキャプチャ
  • Ci::Catalog::Listing クエリのパフォーマンスを追跡するインストルメンテーションの実装
  • ページロード時間のキャプチャ

FY26 の注目事項

• GraphQL サブスクリプションのサポート - エピック
• パイプラインパフォーマンスの改善 - エピック
• CI 変数の改善 - エピック
• MR パイプラインタブの GraphQL への移行 - エピック

興味深いことと達成事項

このセクションには、チームの最近の最も印象的な 3 つの達成事項をリストします。

• 最近、CI/CD カタログを GA リリースしました。
• CI/CD カタログインデックスページに使用統計と人気度ソートオプションを追加しました。

チームメンバー

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

ステーブルカウンターパート

ステーブルカウンターパートを見つけるには、Pipeline Authoring のプロダクトカテゴリリストを参照してください。

ユーザーフィードバックの収集

私たちはユーザーフィードバックを非常に重視しています！最新機能 CI/CD カタログへのフィードバックとインサイトを収集するには、以下の Issue を使用してください:

• CI/CD カタログフィードバック

コミュニティコントリビューション

GitLab でのパイプライン Authoring は、CI/CD システムとそのさまざまなコンポーネントとの複雑な相互作用を深く理解することが必要です。この複雑さはコードベースや基盤となるアーキテクチャに不慣れな人にとって課題となる可能性があります。

コミュニティコントリビューターには ~“seeking community contribution” ラベルの付いた Issue に取り組むことを奨励しています。これらの Issue は外部コントリビューションのための明確で管理しやすいパスを提供するために特別に選択されています。

コミュニティコントリビューション向けにマークされていない Issue へのコントリビューションは、パイプライン Authoring の固有の複雑さにより、かなりのドメイン知識と GitLab の内部への精通が必要な場合があります。すべてのコントリビューションに感謝しますが、これらの Issue への MR はより広範なレビューが必要な場合があり、私たちのアーキテクチャビジョンまたはベストプラクティスと整合しない場合はマージされない場合があります。

レビュアー向けガイダンス

コミュニティコントリビューターからのマージリクエストをレビューする際は、以下を考慮してください:

• Issue の選択: コントリビューションが ~“seeking community contribution” ラベルの付いた Issue に対応しているかを確認します。そうでない場合は、複雑さと必要なドメイン知識を評価します。
• メンタリング: コントリビューションが見込みを示しているが指導が必要な場合は、建設的なフィードバックを提供し、コントリビューターが成功するためのメンタリングの提供を検討します。
• 明確なコミュニケーション: 必要な変更や決定の根拠をコントリビューターがコンテキストと理由を理解できるよう、明確かつ丁重に説明します。

コミュニティが取り上げた Issue に ~‘seeking community contribution’ ラベルがなく、かつ/または複雑すぎる場合は、以下のテンプレートの使用を検討してください:

"GitLab へのコントリビューションに興味を持っていただきありがとうございます！この Issue に取り組んでいただいた主体性を評価します。この特定の領域には、GitLab の CI/CD システムの深いドメイン知識を必要とする複雑さが含まれています。よりスムーズなレビュープロセスとコントリビューションがマージされる可能性を高めるために、~'seeking community contribution' ラベルの付いた Issue に注力することをお勧めします。これらは外部コントリビューター向けに特別にキュレーションされています。厳選された Issue リストはこちらで入手できます: https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=popularity&state=opened&label_name%5B%5D=group%3A%3Apipeline%20authoring&label_name%5B%5D=Seeking%20community%20contributions&first_page_size=100"

グループミーティング

すべてのミーティングには、議論するアジェンダ項目のリストと、ミーティングが行われた際のミーティングメモが含まれていることが期待されます。これにより、出席できない人が追いつきやすくなります。

同期ミーティングのスケジュールは柔軟であり、必要な参加者に合わせて変更できることに注意してください。すべてのチームミーティングの最新スケジュールについては、グループのカレンダーを参照してください。

以下のテーブルは定期チームミーティングの目標と主要な詳細を簡単に説明しています:

ダッシュボード

社内ハンドブックページを参照してください。

クロスファンクショナル優先順位付け

UX、プロダクトマネージャー、エンジニアリングマネージャーは週次ミーティングで、クロスファンクショナルな優先順位付けと、クアッドが協力する必要があるその他のトピックについて議論します。

デザインコラボレーション

デザイン関連のトピックについて議論するためのすべてのチームメンバーに開かれた隔週デザイン同期ミーティングを開催しています。

働き方

計画

Issue は、マイルストーンに割り当てる前に洗練され、重み付けされます。将来のマイルストーンの作業計画に candidate:: スコープラベルを使用します。このラベルにより、workflow::design と workflow::ready for development ラベルが適用されている Issue を計画しているものとしてフィルタリングでき、プロダクト、エンジニアリング、UX が非同期で Issue を洗練させることができます。重み付けはまた、将来のマイルストーンで Issue がスケジュールされる方法に関してキャパシティ計画に役立ちます。

マイルストーン計画プロセスの一部として計画 Issue を作成し、ワークフローボードが現在と今後の作業の情報の単一ソース（SSOT）です。プロダクトがエンジニアリング、UX、テクニカルライターの意見を受けて作業の優先順位付けの DRI です。計画 Issue は質問とチームキャパシティについて議論するために使用されます。各マイルストーンの開始前に、計画 Issue で特定された Issue がそのマイルストーンに割り当てられ、エンジニアはワークフローボードの workflow::ready for development 列の最上位から優先順位付けされた Issue を自分に割り当てることができます。

洗練が必要な Issue を見つける

洗練が必要な Issue は、次のマイルストーンに関連付けられた計画 Issueにリストされています。

エンジニアリングによる Issue の洗練方法

注: 私たちは Grooming よりも Refining を優先します

Issue を洗練する目的は、問題文が大まかな労力見積もりを提供できるほど明確であることを確認することです。洗練中にソリューションの検証を提供することが意図ではありません。

Issue 洗練のチェックリスト

1. Issue の説明に問題文はありますか？
2. Issue に期待される動作が誰でも理解できる程度に十分に説明されていますか？
3. Issue にステークホルダー（例: BE、FE、PM、UX、テクニカルライター）が明示的に定義されていますか？
4. Issue の説明に提案はありますか？ そうであれば:
   1. 提案は問題文に対処していますか？
   2. 実装に意図しない副作用はありますか？
5. Issue に行うべき作業に合った適切なラベルが付いていますか？（例: バグ、機能、パフォーマンス）
6. Issue が type::bug の場合、動作の再現方法が明確であり、サンプル CI 設定ファイルを提供できますか？

このチェックリストの質問への回答にはチームの誰でも貢献できますが、最終的な決定は PM と EM に委ねられます。

サブタスクの使用

Issue の洗練を助けるためにサブタスクを使用します。目標は、バックエンド、フロントエンド、UX、プロダクト、ドキュメントを含む機能のすべての側面に関するスレッドディスカッションを含む 1 つの SSOT Issue を持つことです。

Issue の洗練と重み付けの手順

エンジニアは:

1. 各マイルストーン前に自分に割り当てた Issue について上記のチェックリストを確認します。
2. 定義に基づいてウェイトを追加します。
3. ~workflow:: ラベルを適切なステータスに更新します。例えば:
   • さらなるデザイン洗練が必要な場合は ~“workflow::design”、デザイナーに通知してください。
   • 洗練が完了しウェイトが適用された場合は ~“workflow::ready for development”。これにより実装の準備ができたことを示し、Issue を適切にスケジュールできます。
   • さらなる調査や研究が必要な場合は ~“workflow::planning breakdown”。ステータスは変わらず、PM と EM に通知する必要があります。
4. 洗練と重み付けが完了したら、Issue の割り当てを解除します。

Issue の重み付け

使用するウェイトは:

上記のテーブルは文脈依存です。ドメイン知識、経験レベル、GitLab でのキャリア年数により、Issue に追加調査や驚きが必要かどうかについてのエンジニアの見方が変わる可能性があります。

ウェイトは固定ではありません。洗練中に正確に把握するよう最善を尽くしますが、透明性を確保し正確でありたいと考えています。Issue が既存のウェイトに反映されている以上の労力を要している場合、Issue の DRI はウェイトを変更することが奨励されています。必要とされた労力のレベルを正確にドキュメント化したいと考えています。

5 以上のウェイトのものはすべて細分化する必要があります。これらは ready for development にすべきではありません。

構文の廃止プロセス

CI 構文は進化し続けています。すべてのキーワードを無期限にサポートすることはできないため、キーワードの廃止と削除は避けられません。

GitLab は CI/CD 設定にバージョンシステムを持っていません。そのため、廃止の意図をユーザーに十分に伝え、プロジェクトへの影響を軽減するために必要な予防措置を講じることが重要です。キーワードの廃止はリスクがあります。なぜなら、それを使用しているすべてのパイプラインが壊れ、場合によってはユーザーがパイプラインで使用しているキーワードに気づいていないことがあるためです。以下に説明する廃止プロセスは、CI/CD キーワードの削除に関わるリスクを軽減するための追加手順を持つ機能の廃止と削除プロセスに似ています。

1. 廃止通知 - 構文の削除は破壊的変更をもたらします。廃止プロセスで概説しているように、コミュニティと顧客に通知する必要があります。これは毎月のリリースポストに廃止通知を含めることを意味します。

2. キーワード使用状況の追跡 - キーワード使用状況の追跡はできるだけ早く開始すべきです。これはユーザーへの影響、タイミング、必要な労力を推定するのに役立つ必須ステップです。ユーザーが多くキーワードを使用するほど、それを削除するのにより多くの時間がかかります（type キーワードの削除から廃止まで 4 年以上かかりました）。

3. アプリ内警告 - パイプラインで廃止予定のキーワードを使用しているユーザーに、削除の計画をアプリ内通知で提供します。顧客は廃止予定のキーワードを使用するパイプラインの各実行時に通知を受け取ります。警告は次の場所に表示されます:

   • パイプラインページとログで実行時に。
   • パイプラインの作成中にパイプラインエディタで。

   このステップは、キーワードの使用率が比較的低い場合はオプションです（影響を受けるユーザーの最小リーチとして ~5% を推奨）。

4. キーワードの削除 - キーワードはコードとスキーマから削除され、メジャーバージョンで行われる必要があります。削除後、キーワードを使用するとリントエラーが発生します。

ワークフロー

Pipeline Authoring ワークフロー Issue ボードを使用して、現在のマイルストーンで取り組んでいることを追跡します。

解決する問題が十分に理解され、実装前にソリューションが十分に定義・検証されていることを確保するために、プロダクト開発フローに従います。

UX カウンターパートは SSOT デザインの DRI であり、MR でのエンハンスメントディスカッションを作成・リンクされた Issue での後続の取り組みに移す権利があります。

ワークフローラベルを使用して Issue の状態を効率的に伝えます。これらのラベルを使用することで、チーム間の協力が可能になり、Issue の現在の状態が伝わります。洗練されているがスケジュールされていない（バックログにある）Issue には workflow::scheduling ラベルを適用する必要があります。

ワークフローの各フェーズを通じた DRI は、ワークフローラベルを最新の状態に保つ責任があります。

非同期 Issue 更新

非同期コラボレーションを最適化するために、特定の Issue またはエピックで完了した進捗を共有する Issue 更新を使用します。

進捗とステータスに関する週次更新は、各 Issue の担当者によって追加されます。進捗がなかった場合、週次更新はスキップしても構いません。更新は、全体の進捗の概要を提供しない関連マージリクエストではなく、Issue で提供する必要があります。これは workflow::in dev、workflow::in review、または workflow::design ラベルの付いた Issue に適用されます。

ステータスコメントには、作業が何パーセント完了しているか、見積もりが正確であるという確信度、および何が行われたかの簡単なメモを含めることができます。複数の DRI が Issue に取り組んでいる場合、複数の更新があっても問題ありません。

非同期更新の一部として、Issue と関連 MR のワークフローラベルが正しく設定されていることを確認することが重要です。

例

## Async status update

- Complete: 80%
- Confidence: 90%
- Notes: expecting to go into review tomorrow

機能開発の整合

エンジニアリング DRI は workflow:in dev フェーズを通じてプロダクトデザイナーと協力し、最初に合意したものとは異なる予期しない動作を示す可能性があるソリューションの問題を早期に発見します。最初の Issue で合意していなかった変更が追加される場合は、フォローアップ Issue を作成し、エンジニアリング DRI はプロダクトマネージャーと協力して次のイテレーションにその Issue をスケジュールするべきです。これにより、承認よりクリーンアップに注力し、低い恥の水準で迅速にイテレーションし、合意したことを達成できるようにします。これらのフォローアップ Issue の完了を遅らせないよう注意すべきです。多量の Deferred UX Issue を積み上げないためです。

ソリューションが一貫して合意したデザインと一致しないことが判明した場合、DRI、デザイナー、プロダクトマネージャーでレトロスペクティブを開き、コミュニケーションのギャップがどこにあるかを議論して改善します。特定の Issue の MR に UX 承認を必要とし始める必要があるかもしれません。エンジニアリング DRI が要件を満たすのを支援するためです。

Duo エージェンティックチャットプロンプト

Duo プロンプトを参照してください。

テクニカルデット

• テクニカルデット優先順位ボードを使用してチームのテクニカルデットを追跡します。候補ラベルで今後のマイルストーンを追跡し、現在のマイルストーンと比較します。
• ステージ全体の透明性を高め、コラボレーションが必要な場合に役立てるため、2024 年 8 月から、Pipeline チームのトップ優先テクニカルデットを示す Verify パイプラインチームテクニカルデットボードを導入しました。

レトロスペクティブ

現在の Pipeline Authoring レトロスペクティブを表示.

チームコミュニケーション

共有チームカレンダー

Pipeline Authoring チームには、Time Off by Deel の重要な日程をチームに通知するために #g_pipeline-authoring Slack チャンネルと統合した共有カレンダーがあります。

Verify:Pipeline Authoring カレンダーとの統合方法はこちらをご覧ください。

開発者オンボーディング

Verify での開発者オンボーディングセクションを参照してください。

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