ステーブルブランチ

概要

ステーブルブランチは、GitLab のお客様に提供される GitLab リリースパッケージのソースです。 バージョン管理されたリリースの基盤として機能し、あらゆる GitLab リリースプロセス（月次、パッチ、内部）で 信頼できる状態を保つことが不可欠です。

原則

• GitLab では、ステーブルブランチのテストを成功させ、信頼できる状態に保つことは全員の責任です。master ブランチの失敗と同様に、ステーブルブランチの失敗への対応は、開発に関連するほかのすべての作業より優先されます。
• ステーブルブランチには、メンテナンスポリシーに従ってバグ修正とセキュリティパッチが適用されます。
• ステーブルブランチには、維持管理の取り組みや、遅れていた修正・改善（パフォーマンス改善、ドキュメント更新、スペックの修正など）も適用できます。

ワークフロー

1. ステーブルブランチは、月次リリースの最初のリリース候補にタグが付けられるときに作成されます。
2. 作成後、ステーブルブランチはリポジトリミラーリングを通じてsecurityおよびdevリポジトリに自動的に反映されます。
3. バグ修正とセキュリティ修正は、ステーブルブランチにバックポートされます。これはメンテナンスポリシーに基づいて行われます。
4. ステーブルブランチにバックポートされた変更は、その GitLab バージョンとの互換性を保証するため、リリース環境に自動的にデプロイされます。
5. パッチリリースと内部リリースは、ステーブルブランチの内容から作成されます。

特性

• ステーブルブランチの権限は、メンテナンスポリシーに基づきます。 メンテナンス対象バージョンに関連付けられたステーブルブランチでは GitLab メンテナーがマージできますが、古いステーブルブランチでは Release Managers のみに制限されます。
• セキュリティ修正とリリース環境を考慮し、security リポジトリがステーブルブランチの SSOT となります。
• ステーブルブランチのテストは canonical リポジトリと security リポジトリで同じです。ただし、GitLab security リポジトリでのみ利用できるリリース環境は例外です。

ビルドインフラストラクチャ

リリースアーティファクトは、専用の CI ランナーインフラストラクチャを使い、ミラーリングされたリポジトリからビルドされます。 どのミラーが存在するか、何がどこでビルドされるか、このアーキテクチャを採用した理由の詳細については、 ビルドインフラストラクチャのドキュメントを参照してください。

壊れたステーブルブランチ

ステーブルブランチのパイプラインが失敗すると、triage-ops がgitlab-org/release/tasksにインシデントを作成し、#releases に投稿します。壊れたステーブルブランチはパッチリリースやセキュリティリリースをブロックする可能性があるため、Release Managers がこれらのインシデントを監視します。これらは CI Health のインシデントではなく、自動的にはエスカレーションされません。

失敗のトリアージや修正を行うには、インシデントを割り当てられた場合の手順に従ってください。

しきい値を超えたステーブルブランチ

• ステーブルブランチのパイプラインがしきい値を超えると（過去 7 日間）、canonicalプロジェクトに Issue が作成され、automation:pipeline-duration-threshold ラベルが付けられます。
• daily_pipeline_thresholdsが Issue を作成し、過去 24 時間のさらなるしきい値違反も、既存の Issue へのコメントとして更新します。
• 最新の 3 つのステーブルブランチについて、ステーブルブランチとパイプラインティアの組み合わせごとに、一意の Issue が作成されます。

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