- 前提条件
engineering
グループを作成します。- サブグループは
engineering
- サブグループにユーザーを追加します。
- Excelsiorプロジェクトを作成します。
- 基本的なCODEOWNERSファイルの追加
- 承認者の設定
- ブランチのCODEOWNER承認者の強制
- リリースブランチの作成
チュートリアルプロジェクト用の保護されたワークフローの構築
あなたのチームが新しいプロジェクトを始めるとき、効率と適切なレビューのバランスが取れたワークフローが必要です。GitLabでは、ユーザーグループを作成し、それらのグループをブランチ保護と組み合わせ、承認ルールでそれらの保護を強制することができます。
このチュートリアルでは、Excelsior Project の1.x
と1.x.x
リリースブランチの保護を設定し、プロジェクトの最小限の承認ワークフローを作成します:
-
engineering
グループを作成します。 - サブグループを
engineering
- サブグループにユーザーを追加
- Excelsiorプロジェクトの作成
- 基本的なCODEOWNERSファイルを追加
- 承認者の設定
- ブランチに対するCODEOWNER承認の強制
- リリースブランチの作成
前提条件
- メンテナーまたはオーナーのロールを持っている必要があります。
- 管理者のリストとメールアドレスが必要です。
- バックエンドエンジニアとフロントエンドエンジニアのリストとメールアドレス。
- ブランチ名のセマンティックバージョニングを理解していること。
engineering
グループを作成します。
Excelsior Projectをセットアップする前に、プロジェクトを所有するグループを作成する必要があります。ここでは、Engineeringグループを設定します:
- 左サイドバーの上部にある、新規作成…({プラス})と新規グループを選択します。
- グループの作成]を選択します。
-
グループ名には
Engineering
を入力します。 -
グループの URL には
engineering
と入力してください。 - 可視性のレベルを非公開に設定します。
- GitLabがあなたに最も役立つ情報を表示するように、あなたの体験をパーソナライズしてください:
- ロールは システム管理者を選択してください。
- このグループを使用する人]は、[私の会社またはチーム]を選択します。
- このグループを何に使用しますか?自分のコードを保存したい」を選択してください。
- グループにメンバーを招待するのをスキップします。このチュートリアルの後のセクションでユーザーを追加します。
- グループの作成]を選択します。
次に、このengineering
グループにサブグループを追加して、より詳細なコントロールを行います。
サブグループはengineering
engineering
グループは良いスタートですが、Excelsior Project のバックエンドエンジニア、フロントエンドエンジニア、マネージャーにはそれぞれ異なるタスクがあり、専門分野も異なります。
ここでは、Engineering グループにさらに詳細なサブグループを 3 つ作成し、ユーザーを仕事のタイプ別にセグメンテーションします:managers
frontend
およびbackend
。そして、これらの新しいグループをengineering
グループのメンバーとして追加します。
まず、新しいサブグループを作成します:
-
左のサイドバーで「検索」を選択するか、「
engineering
」を検索します。Engineering
という名前のグループを選択します: -
engineering
グループの概要ページで、右上隅にある「新しいサブグループ」を選択します。 -
サブグループ名に
Managers
と入力します。 - 可視性のレベルを非公開に設定します。
- サブグループの作成]を選択します。
次に、engineering
グループのメンバーとしてサブグループを追加します:
- 左のサイドバーで「検索」を選択するか、「
engineering
」を検索します。Engineering
という名前のグループを選択します。 - 左側のサイドバーで、[管理] > [メンバー]を選択します。
- 右上の「グループを招待」を選択します。
-
招待するグループを選択するには、
Engineering / Managers
を選択します。 - サブグループを追加するときは、ロール「メンテナー」を選択します。これは、
engineering
グループとそのプロジェクトにアクセスする際に、サブグループのメンバーが継承できる最高のロールを設定します。 - オプション。有効期限を選択します。
- 招待]を選択します。
このプロセスを繰り返して、backend
とfrontend
のサブグループを作成します。完了したら、engineering
グループをもう一度検索します。その概要ページには、次のように3つのサブグループが表示されているはずです:
サブグループにユーザーを追加します。
前のステップで、サブグループを親グループ(engineering
)に追加したときに、サブグループのメンバーをメンテナーのロールに制限しました。これは、engineering
が所有するプロジェクトに対して継承できる最高のロールです。その結果
- ユーザー 1 は Guest ロールで
manager
サブグループに追加され、engineering
プロジェクトで Guest ロールを受け取ります。 - ユーザー2はオーナーロールで
manager
グループに追加されます。このロールは設定した最大ロール(メンテナー)より高いので、ユーザー2はオーナーではなくメンテナーのロールを受け取ります。
frontend
サブグループにユーザーを追加するには:
- 左サイドバーで「検索」を選択するか、「
frontend
」を検索します。Frontend
グループを選択します。 - 管理 > メンバーを選択します。
- メンバーを招待] を選択します。
- フィールドに入力します。デフォルトでは開発者ロールを選択し、このユーザーが他のユーザーの作業をレビューする場合はメンテナーに増やします。
- 招待]を選択します。
-
frontend
サブグループにすべてのフロントエンドエンジニアを追加するまで、この手順を繰り返します。
backend
とmanagers
グループも同様にします。同じユーザーが複数のサブグループのメンバーになることができます。
Excelsiorプロジェクトを作成します。
グループ構成が整ったので、excelsior
各チームが作業するプロジェクトを excelsior
作成します。excelsior
フロントエンドエンジニアとバックエンドエンジニアの両方が関わるので excelsior
、先ほど作成した小さなサブグループではなく、engineering
。
新しいexcelsior
プロジェクトを作成します:
- 左のサイドバーで、Search を選択するか、
engineering
を検索します。Engineering
という名前のグループを選択します。 -
engineering
グループの概要ページで、左サイドバーの上部にある「新規作成…({plus})」と「このグループで > 新規プロジェクト/リポジトリ」を選択します。 - 空白プロジェクトの作成」を選択します。
- プロジェクトの詳細を入力します:
-
プロジェクト名フィールドに
Excelsior
と入力します。プロジェクトのスラッグにはexcelsior
が自動入力されます。 - Visibility Level(可視レベル)]で[公開]を選択します。
- Initialize repository with a READMEを選択して、リポジトリに初期ファイルを追加します。
-
プロジェクト名フィールドに
- Create projectを選択します。
GitLab がexcelsior
プロジェクトを作成し、そのホームページにリダイレクトします。このようになります:
次のステップでは、このページの機能を使います。
基本的なCODEOWNERSファイルの追加
プロジェクトのルートディレクトリにCODEOWNERSファイルを追加して、レビューを適切なサブグループにルーティングします。この例では4つのルールを設定しています:
- すべての変更は
engineering
グループの誰かによってレビューされるべきです。 - CODEOWNERSファイル自体の変更は、マネージャーがレビューしてください。
- フロントエンドエンジニアはフロントエンドファイルの変更をレビューすべきです。
- バックエンドエンジニアはバックエンドファイルの変更をレビューしてください。
excelsior
プロジェクトに CODEOWNERS ファイルを追加するには:
- 左のサイドバーで「検索」を選択するか、「
Excelsior
.Excelsior
というExcelsior
名前のプロジェクトを選択Excelsior
します。 - ブランチ名の横にあるプラスアイコン({plus})を選択し、New fileを選択します:
-
ファイル名には
CODEOWNERS
.CODEOWNERS
プロジェクトのルートディレクトリにCODEOWNERS
ファイルが作成CODEOWNERS
されます。 -
この例を編集エリアに貼り付けます。
@engineering/
、グループ構成に合わない場合は変更してください:# All changes should be reviewed by someone in the engineering group * @engineering # A manager should review any changes to this file CODEOWNERS @engineering/managers # Frontend files should be reviewed by FE engineers [Frontend] @engineering/frontend *.scss *.js # Backend files should be reviewed by BE engineers [Backend] @engineering/backend *.rb
-
コミットメッセージの場合は、次のように貼り付けてください:
Adds a new CODEOWNERS file Creates a small CODEOWNERS file to: - Route backend and frontend changes to the right teams - Route CODEOWNERS file changes to managers - Request all changes be reviewed
- 変更をコミット を選択します。
これで、CODEOWNERS ファイルがプロジェクトのmain
ブランチに配置され、今後このプロジェクトで作成されるすべてのブランチで使用できるようになりました。
承認者の設定
CODEOWNERS ファイルには、ディレクトリとファイルタイプに適切なレビュアーが記述されています。承認ルールはマージリクエストをこれらのレビュアーに指示します。ここでは、新しい CODEOWNERS ファイルの情報を使用し、リリースブランチの保護を追加する承認ルールを設定します:
- 左側のサイドバーで、設定 > マージリクエストを選択します。
- マージリクエスト承認者セクションで、承認ルールまでスクロールします。
- 承認ルールの追加を選択します。
-
Enforce CODEOWNERS
という名前のルールを作成します。 - すべての保護ブランチを選択します。
- このルールをGitLab PremiumとGitLab Ultimateで必須にするには、Approvals requiredを
1
に設定します。 -
managers
グループを承認者として追加します。 - 承認ルールの追加を選択します。
- 承認設定までスクロールし、[マージリクエストで承認ルールを編集しない] が選択されていることを確認します。
- 変更を保存を選択します。
追加すると、Enforce CODEOWNERS
ルールは次のようになります:
ブランチのCODEOWNER承認者の強制
プロジェクトに対していくつかの保護を設定しました。これらの保護を組み合わせて、プロジェクトの重要なブランチを保護する準備ができました:
- ユーザーは論理グループとサブグループに分類されます。
- CODEOWNERSファイルには、ファイルタイプやディレクトリのサブジェクトマターエキスパートが記述されています。
- あなたの承認ルールは、(GitLab Freeの場合)サブジェクトマターエキスパートに変更をレビューするよう促すか、(GitLab PremiumとGitLab Ultimateの場合)要求します。
あなたのexcelsior
プロジェクトでは、リリースブランチの名前にセマンティックバージョニングを使っています。そのため、リリースブランチは1.x
と1.x.x
というパターンに従っていることがわかります。これらのブランチに追加されたコードはすべて担当者のレビューが必要で、どの作業をリリースブランチにマージするかは管理者が最終決定する必要があります。
ブランチを一度に保護するのではなく、ワイルドカードブランチルールを設定して複数のブランチを保護します:
- 左側のサイドバーで、設定 > リポジトリ を選択します。
- 保護されたブランチを展開します。
-
ブランチ] ドロップダウン リストから、「
1.*
」と入力し、「ワイルドカードを作成する」 を選択します1.*
。 - コミットを直接プッシュするのではなく、全員がマージリクエストを提出するようにします:
- セットAllowed to merge to Maintainers.
- SetAllowed to push and merge to No one.
- Allowed to force push を無効のままにします。
- GitLab Premium と GitLab Ultimate では、コードオーナーが作業しているファイルへの変更をレビューすることを要求するには、Require approval from code owners を切り替えます。
- Protect を選択します。
- ブランチの表で、
Default
とマークされたルールを探します。(GitLab のバージョンによっては、このブランチはmain
またはmaster
という名前になっているかもしれません。)このブランチの値を、1.*
のルールで使った設定と同じになるように設定します。
1.*
ブランチがまだ存在しないにもかかわらず、ルールが設定されました:
リリースブランチの作成
これでブランチの保護がすべて整ったので、1.0.0 リリースブランチを作成する準備ができました:
- 左のサイドバーで、コード > ブランチを選択します。
- 右上の [新規ブランチ] を選択します。名前を
1.0.0
とします。 - ブランチを作成 を選択します。
ブランチの保護がUIに表示されました:
-
左のサイドバーで、コード > ブランチを選択してください。ブランチのリストで、ブランチ
1.0.0
が保護されていることを示すはずです: -
左のサイドバーで、設定 > リポジトリ を選択し、ブランチのルールを展開すると、保護されているブランチの詳細が表示されます:
おめでとうございます!エンジニアはそれぞれの機能ブランチで独立して作業することができ、1.0.0 リリースブランチの検討用に提出されたコードはすべて、専門家によってレビューされます。