- 前提条件
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 リリースブランチの検討用に提出されたコードはすべて、専門家によってレビューされます。






