ステーブルブランチ
概要
ステーブルブランチは、GitLabのお客様に提供されるGitLabリリースパッケージのソースです。バージョン管理されたリリースの基盤として機能し、あらゆるGitLabリリースプロセス（マンスリー、パッチ、内部）において確実に信頼できる状態を保つことが基本です。
原則
- GitLabでは、ステーブルブランチをグリーンで信頼できる状態に保つことは全員の責任です。masterブランチの障害と同様に、ステーブルブランチの障害への対応は開発に関連するその他のすべてのことよりも優先されます。
- ステーブルブランチはメンテナンスポリシーに従ってバグ修正とセキュリティパッチを受け取ります。
- ステーブルブランチは維持管理の取り組みやキャッチアップ的な修正改善（パフォーマンスの改善、ドキュメントの更新、specの修正など）も受け取ることができます。
ワークフロー
- ステーブルブランチはマンスリーリリースの最初のリリース候補にタグが付けられるときに作成されます。
- 作成後、ステーブルブランチはリポジトリミラーリングを通じてsecurityおよびdevリポジトリに自動的に伝播されます。
- バグとセキュリティ修正はメンテナンスポリシーに基づいてステーブルブランチにバックポートされます。
- ステーブルブランチにバックポートされた変更は、GitLabバージョンとの互換性を保証するためにリリース環境に自動的にデプロイされます。
- パッチリリースと内部リリースはステーブルブランチのコンテンツから作成されます。
特性
- ステーブルブランチのアクセス権限はメンテナンスポリシーに基づいています。メンテナンス対象バージョンに関連付けられたステーブルブランチはGitLabメンテナーがマージできるようにオープンになっており、古いステーブルブランチはリリースマネージャーのみに制限されています。
- セキュリティ修正とリリース環境を考慮して、セキュリティリポジトリがステーブルブランチのSSOTとなります。
- ステーブルブランチのテストは正規リポジトリとセキュリティリポジトリで同じですが、GitLabセキュリティリポジトリのみで利用可能なリリース環境を例外とします。
ビルドインフラストラクチャ
リリースアーティファクトはミラーリングされたリポジトリから専用のCIランナーインフラストラクチャを使用してビルドされます。 どのミラーが存在するか、何がどこでビルドされるか、およびこのアーキテクチャの背後にある理由の詳細については、ビルドインフラストラクチャドキュメントを参照してください。
壊れたステーブルブランチ
ステーブルブランチのパイプラインが失敗した場合、壊れたmasterインシデントと同じエスカレーションプロセスに従います。ただし、1つの重要な違いがあります: インシデントはmaster-broken-incidentsプロジェクトではなく、gitlab-org/release/tasksプロジェクトに作成されます。
プロセスの概要:
- オートメーションがステーブルブランチの障害を検出し、適切なグループ/カテゴリラベルを付けてインシデントを作成します
- Slack通知が帰属するグループチャンネルに送信されます
- masterの壊れたインシデントと同じトリアージ、エスカレーション、解決手順が適用されます
- インシデントは対処されない場合、同じ4時間のエスカレーションタイムラインに従います
エンジニアはステーブルブランチのインシデントをmaster-broken-incidentsと同じ優先度で扱う必要があります。これらは重要なリリースとセキュリティパッチをブロックする可能性があるためです。
しきい値を超えたステーブルブランチ
- ステーブルブランチのパイプラインがしきい値（過去7日間）を超えると、Issueが正規プロジェクトに作成され、
automation:pipeline-duration-thresholdラベルが付けられます。 - daily_pipeline_thresholdsはIssueの作成と、過去24時間のしきい値違反の更新を既存のIssueへのコメントとして実行する責任があります。
- Issueは最新の3つのステーブルブランチについて、ステーブルブランチとパイプラインティアの組み合わせに基づいて一意に作成されます。
