はじめに
前回は、GitLabの画面と主要な機能について解説しました。今回は、GitLabの最も基本的な単位であるプロジェクトに焦点を当てます。GitLabのプロジェクトが提供するユニークな価値と、それを最大限に活用する方法を解説します。
グループとプロジェクトの関係
GitLabのプロジェクトを最大限に活用するには、まずグループの概念を理解することが重要です。グループは、複数のプロジェクトをひとまとめにして管理するためのコンテナです。例えば、「Web開発チーム」というグループを作り、その中に「フロントエンド」「バックエンド」「API」といった複数のプロジェクトを配置することができます。
この階層構造には、次のような大きなメリットがあります。
- グループに設定したメンバーのアクセスレベルは、そのグループ内のすべてのプロジェクトに自動的に適用されます。これにより、プロジェクトごとに個別の権限設定を行う手間が省けます。
- グループ単位でイシューボードやCI/CD変数、セキュリティポリシーなどを設定できます。複数のプロジェクトにまたがるタスクや、共通の設定を効率的に管理できます。
プロジェクトの機能
GitLabにおけるプロジェクトの役割は開発の最初から最後まで、チームの作業全体を統合管理する場所になります。GitLabのプロジェクトは、以下のすべてを一つの場所に集約しています。
- リポジトリ:プロジェクトのすべてのコードを保管する場所です。チームメンバーは、ブランチを切ってコードを編集し、変更履歴をコミットすることで、コードベースの変更を管理します。
- マージリクエスト:ブランチの変更を、mainなどの共有ブランチに統合するための機能です。コード統合だけでなく、チームメンバーによるコードレビューや議論、そしてCI/CDパイプラインの実行結果を確認する場所としても機能します。
- イシュー管理:タスク、バグ、新機能などの作業を追跡・管理する場所です。イシューに担当者を割り当てたり、進捗状況をボードで可視化したりすることで、プロジェクトの作業を一元的に把握し、効率的な開発をサポートします。
- CI/CD:CI/CD(継続的インテグレーション・継続的デリバリー)は、コードのテスト、ビルド、デプロイを自動化する仕組みです。gitlab-ci.ymlという設定ファイルに記述されたパイプラインが自動で実行され、開発プロセスを効率化します。
- Wiki:プロジェクトのドキュメントやナレッジを保管する場所です。Gitリポジトリとは別に管理されるため、API仕様書や環境構築手順など、チームで共有すべき情報を整理し、常に最新の状態を保つのに役立ちます。
- セキュリティ:コードの脆弱性や機密情報を自動で検知する仕組みです。CI/CDパイプラインに組み込まれたスキャンが、開発の初期段階から潜在的なセキュリティリスクを発見し、安全なコードベースを維持するのに貢献します。
これは、単一のプラットフォームで開発ライフサイクル全体を管理するというGitLabの哲学を体現しています。プロジェクトを作成するだけでコード管理からテスト・デプロイまでを効率的に進めることができます。
プロジェクトを最大限に活用する実践的な方法
GitLabのプロジェクトは、ただコードを置くだけでなく、以下の機能を活用することで、その真価を発揮できます。
ユーザー招待
プロジェクトの「メンバー」から、チームメンバーを招待し、それぞれの役割を設定します。これにより、適切な権限で共同作業を始めることができます。ユーザー招待時には 期限付きのアクセス権 を設定することも可能です。外部ベンダーや短期間だけ関わるメンバーに対して有効で、不要になったあと自動的に権限を失効させることでセキュリティリスクを低減できます。
グループ単位での招待を活用すれば、同じチームメンバーを複数プロジェクトにまとめて参加させることもできます。これにより、効率的かつ統一的にメンバー管理が行えます。
権限設定
GitLabでは、ユーザーに付与する権限(ロール)によってプロジェクトやグループ内での操作範囲を細かくコントロールできます。これにより「誰が何をできるか」を明確にし、誤操作やセキュリティリスクを防ぐことができます。
以下はよく使われる代表的な権限例の一例です。
- プロジェクトレベルの権限
各プロジェクトごとに付与される権限で、主に日々の開発作業に関わる役割を定義します。- Owner:プロジェクトの最上位権限を持ち、全ての操作が可能です。プロジェクトの削除や移動も含まれ、最大の権限を持ちます。基本的にはプロジェクトやグループの責任者やシステム管理者に付与されます。
- Maintainer:主にプロジェクト管理者として設定変更、保護ブランチ管理、メンバー招待・管理などが可能です。Ownerほどの権限はなく、プロジェクトの設定を統括します。プロジェクトの削除や移動などはできません。
- Developer:日常的な開発者権限で、ブランチ作成やコードのプッシュ、マージリクエストの作成・承認などができますが、プロジェクトの設定変更やメンバー管理はできません。
- グループレベルの権限
- 複数のプロジェクトを束ねるグループ単位でも権限を設定できます。グループに属する全プロジェクトに影響するため、組織全体での権限設計に有効です。例えば、あるユーザーをグループでDeveloperとして登録すれば、そのグループ配下のすべてのプロジェクトで開発者権限を持つことになります。逆に、個別のプロジェクト単位で追加の権限を付与することも可能です。
このように、グループとプロジェクト双方の権限設定を適切に使い分けることで、日常の開発作業はプロジェクト権限で細かくコントロールしつつ、グループ権限で全体の統制を効かせるといった柔軟な運用が可能になります。
公式ドキュメント:https://docs.gitlab.com/user/permissions/
保護ブランチ
main ブランチなど、特定の重要なブランチに対して直接の変更を制限する機能です。通常、開発者は自分のブランチで作業し、レビューを経てからmainブランチに統合します。しかし、誤って直接mainにプッシュしてしまうと、予期せぬバグが本番環境にデプロイされ、システム全体が停止するような大事故につながる可能性があります。保護ブランチ機能は、誤ってコードがブランチにプッシュされることを防ぎ、開発の安定性を確保できます。
設定 >リポジトリ から設定できます。
wiki
コードとは別に、プロジェクト固有のドキュメントを管理できる仕組みです。API仕様書、開発環境のセットアップ手順、リリースノートなど、チームで繰り返し参照する情報を整理するのに最適です。ドキュメントがプロジェクトと一緒に管理されるため、常に最新の情報を共有できます。
開発を始めるまでの準備
開発を始めるとき、まずは以下の準備を行いましょう。
GitLabにログイン済みであることを前提とします。
グループの作成
複数のプロジェクトを管理する予定がある場合は、まずグループを作成します。グループの作成は、GitLabのグループ画面から「新しいグループ」をクリックします。
「グループを作成」をクリックします。
グループ名、表示レベルを設定して「グループの作成」をクリックします。
これでグループの作成は完了です。
グループメンバーの招待
グループの管理>メンバーから、チームメンバーを招待し、適切な権限を付与します。
「メンバーを招待」をクリックします。
今回はメンテナーと開発者を追加したいと思います。
ユーザーとロール、アクセスの有効期限を設定して、「招待」をクリックします。
プロジェクトの作成
作成したグループ内で、新しいプロジェクトを作成します。グループのホーム画面から「新しいプロジェクト」をクリックします。
「空のプロジェクトの作成」をクリックします。
プロジェクト名、表示レベルなどを設定して、「プロジェクトを作成」をクリックします。
今回は、デフォルト設定のままプロジェクトを作成することを前提とします。
表示レベルは、誰がプロジェクトにアクセスできるかを定義します。
- 非公開 (Private):プロジェクトメンバーだけがアクセスできます。
- GitLabで最も推奨される設定です。コードやイシュー、CI/CDパイプラインなど、すべての情報がチーム内のみで共有されます。
- 内部 (Internal):ログインしているすべてのユーザーがアクセスできます。
- GitLabインスタンスの全ユーザー(例:社内の全従業員)がプロジェクトを閲覧できます。社内向けの共通ライブラリやドキュメントを共有するのに便利です。
- 公開 (Public):ログインしていないユーザーも含め、誰でもアクセスできます。
- オープンソースプロジェクトなど、広く一般に公開したい場合に選択します。機密情報や社内情報を含むプロジェクトでは使用しないでください。
通常、機密情報が含まれるプロジェクトでは非公開を、ログイン済みユーザーなら誰でも参照可能なプロジェクトでは内部を選択することを強く推奨します。
プロジェクトの設定には、リポジトリの初期状態を決める追加オプションがあります。
デフォルトでは、「READMEを作成する」にのみチェックが入っています。これは、プロジェクト作成と同時に、簡単な説明が記載されたREADME.mdファイルが自動で作成される設定です。
プロジェクトの画面が表示されたら作成完了です。
ブランチ保護の設定
プロジェクトの初期設定をしていきます。まずはブランチ保護の設定です。
ブランチ戦略にもよりますが、ここではmainブランチへの直接のプッシュを制限し、マージの権限設定をします。
設定>リポジトリ から、保護ブランチを開きます。
mainブランチに対してのマージを許可するロールとプッシュを許可するロールを選択します。強制プッシュを許可するかも選択します。developブランチなどにも保護ブランチ設定をしたい場合は、「保護ブランチを追加する」をクリックします。
Wikiの作成
続いて、Wikiを作成しておきます。こちらは必須ではないですが、プロジェクトの概要やルールなどをWikiに記載し、チームで共有することで円滑な開発が可能になります。環境構築の手順、API仕様書などがあればWikiに追加しておきましょう。
計画>Wikiから、「最初のページを作成」をクリックします。
タイトルや内容を記述し、「ページを作成」をクリックします。
ページが表示されたら完了です。
これでプロジェクトの準備は完了です。
あとは、リモートプロジェクトをローカル環境に取得したら、ローカルでの開発作業を開始できます。リモートプロジェクトのクローンは第4回のブログを参考にしてみてください。
まとめ
今回の記事では、GitLabのプロジェクトについて深く掘り下げました。GitLabのプロジェクトは、コード、イシュー、CI/CD、Wiki、セキュリティといったすべてを統合していました。
さらに、グループを活用することで、複数のプロジェクトを効率的に管理し、メンバーの権限設定を簡素化できることを解説しました。そして、実際にプロジェクトの作成から、保護ブランチやWikiの設定といった初期準備までを実践しました。
次回は、GitLabのCI/CDに焦点を当てます。今回設定したプロジェクト上で、コードのビルド、テスト、デプロイといった一連のプロセスを自動化する方法を、簡単に解説します。
参考文献
https://docs.gitlab.com/user/group/
https://docs.gitlab.com/user/project/members/sharing_projects_groups/
https://docs.gitlab.com/user/permissions/