FJcloud実践
DevOps with GitLabではじめるGitLab入門
GitLabは、Gitをベースとしたソースコード管理システムです。とはいえ、GitLabは単なるソースコード管理だけでなく、イシュー管理、マージリクエスト、CI/CD パイプラインなど、ソフトウェア開発のライフサイクル全体をサポートする統合プラットフォームとして機能します。Webベースのインターフェイスを備えており、DevOpsのプラットフォームとして広く利用されています。
FJcloud-Vの「DevOps with GitLab」は、クラウド上でのDevOps開発をサポートするマネージドサービスです。簡単にクラウド上でGitLabインスタンスを立ち上げ、すぐに利用を始めることができます。その際、オンプレミス環境のような、複雑なセットアップは必要ありません。
本記事では、DevOps with GitLabを例に、GitLabの基本的な使い方を解説します。なお前回の記事に沿って、FJcloud-V上にDevOps with GitLabサービスを構築し、rootユーザーでGitLabにログインできる状態であることを前提としています。
ユーザーとグループの管理
チーム開発を始める前に、まずは開発メンバーのユーザーアカウントを作成し、適切な権限管理を行う必要があります。セキュリティ的な理由からも、最初に作られたrootアカウントを使い回すようなことは避けましょう。
新規ユーザーの作成
まずrootユーザーでGitLabにログインしてください。左サイドバーの一番下にある「Admin」をクリックして、Adminエリアに入ります。
左サイドバーの「Overview」→「Users」をクリックすると、右側に現在のユーザー一覧が表示されます。ここで右上にある「New user」をクリックします。
ユーザー作成画面に遷移します。ユーザーの名前、ログインユーザー名、メールアドレスを入力します。ここで入力したメールアドレス宛てに、パスワードのリセット用のリンクが送信されるため、間違えないように気をつけてください。
ユーザーのアクセス権限を設定します。「Regular」は自分が所有、もしくは所属しているプロジェクト等にのみアクセスできる、一般ユーザーです。対して「Administrator」は、すべての機能に無制限にアクセスできます。通常の利用者の場合は、必ず「Regular」としてください。それ以外はデフォルトのままで構いません。各項目の詳しい説明は、ドキュメントを参照してください。
「Create user」をクリックすると、実際にユーザーが作成されます。ユーザーのメールアドレス宛てに、以下のようなメールが届きますので、各ユーザーはメールの指示に従ってパスワードの設定を行ってください。
グループの作成
GitLabにおけるグループとは、複数のユーザーをまとめて管理する仕組みです。グループを活用することで、メンバーの権限の一元管理が可能になります。GitLabはコラボレーションツールですから、チームに所属する複数のメンバーがそれぞれアカウントを持ち、利用することになるでしょう。こうした時に、チームごとにグループを作成しておくと、効率よく管理できます。
グループを作成するには、左サイドバーからAdminエリアに入り、「Overview」→「Groups」をクリックします。ここで右上にある「New group」をクリックします。
グループの作成画面が開きますので、グループの名前を入力してください。それ以外の設定は、基本的にデフォルトのままで構いません。各設定項目の詳細はドキュメントを参照してください。「Create group」をクリックすると、グループが作成されます。
グループが作成できたら、メンバーを追加しましょう。Adminエリアの「Overview」→「Groups」をクリックし、表示されたグループ一覧から、先ほど作成したグループ(group01)をクリックします。右側にメンバーのリストが表示されますので、「Manage access」をクリックします。
グループメンバーの管理画面が表示されますので、右上の「Invite members」をクリックします。
メンバーの追加ダイアログが表示されますので、先ほど作成したユーザーを追加しましょう。グループ内におけるユーザーの権限は、ドキュメントを参照して決定してください。ここでは、プロジェクトに完全な権限のある「Owner」としました。「Access expiration date」は、そのアカウントの有効期限です。通常であれば空欄(無期限)でよいでしょう。一時的にグループに参画するようなユーザーがいる場合は、活用してみてください。
「Invite」をクリックすると、そのユーザーがグループに追加されます。
プロジェクトの作成
ユーザーとグループが作成できたら、共同作業のためのプロジェクトを作成しましょう。なお、ここからの作業はrootではなく、一般ユーザーの権限で行います。作成したユーザーアカウントでGitLabにログインしてください。
新規プロジェクト作成
左上にある「+」アイコンをクリックして、「New project/repository」を選択します。
プロジェクトをどのように作るかを選択します。ここでは空のプロジェクトを作成したいため、「Create blank project」をクリックしてください。テンプレートに従ってプロジェクトを作成したり、GitHubや他のGitLabからプロジェクトをインポートすることも可能です。
プロジェクト作成の画面が表示されたら、プロジェクトの名前を入力してください。また、「Project URL」のプルダウンをクリックして、そのプロジェクトの所有者を決定します。基本的に自分自身と、自分が所属し、権限のあるグループが選択できます。自分自身を選択すると、そのユーザーが所有するプロジェクトとなり、グループを選択すると、グループが所有するプロジェクトになります。ここでは先ほど参画した、group01グループのプロジェクトとしました。
Visibility Levelではプロジェクトの可視性を選択します。なお、グループ所有のプロジェクトとした場合、グループに設定された可視性が、プロジェクトが選択できる可視性の上限となります。今回作成したgroup01は、Privateなグループのため、プロジェクトの可視性もPrivateしか選べません。
最後に「Create project」をクリックすると、プロジェクトが作成されます。
リポジトリの基本操作
リポジトリのクローン
当然ですが、GitLabのプロジェクトには、Gitリポジトリが含まれています。しかし、初期状態では、リポジトリの中は空です。そこで、リポジトリをクローンして、コードを追加してみましょう。あらかじめ、手元のPCでGitコマンドを使えるようにしておいてください。
左サイドバーから「Projects」を開き、「Member」タブをクリックしてください。自分が所属するプロジェクトの一覧が表示されます。先ほど作成したプロジェクトをクリックしてください。
以下のような、プロジェクトのトップページが表示されます。ここで「Code」をクリックします。
すると、以下のようにGitのCloneに必要なURLが表示されますので、「Clone with HTTPS」のURLをコピーしてください。
ターミナルを開き、gitコマンドを実行します。GitLabのユーザー名とパスワードを尋ねられますので、自分のアカウントのユーザー名とパスワードを入力しましょう。これで、空のリポジトリが「new_project」ディレクトリにクローンされます。
$ git clone コピーしたURL new_project
Cloning into 'new_project'...
Username for 'https://コピーしたURL': user01
Password for 'https://user01@コピーしたURL':
warning: You appear to have cloned an empty repository.ファイルの追加・編集・コミット
クローンしたディレクトリへ移動します。
$ cd new_projectプロジェクトの概要を説明する、README.mdファイルを追加してみましょう。
$ cat > README.md <<EOF
このプロジェクトは、DevOps with GitLabのサンプルプロジェクトです。
EOF作成したREADME.mdを、Gitリポジトリへ追加します。
$ git add README.md
$ git commit -m 'first commit'
リモートリポジトリへのpush
追加したファイルのコミットは完了しましたが、この変更はまだ、手元にクローンしたローカルリポジトリ上にしか存在しません。プロジェクトでこの変更を共有できるよう、GitLabに変更を送り込む必要があります。これをPushと呼びます。以下のコマンドを実行しましょう。
$ git push -u origin main変更がPushされ、GitLabのプロジェクトページにファイルが表示されるようになりました。
なお、gitコマンドの詳しい使い方については、本記事の範囲外となるため解説しません。別途コマンドのマニュアル等を参照してください。
イシューでタスク管理
イシューとは、バグレポート、機能要求、作業タスクなどを管理するGitLabの機能です。チーム開発においては、タスク管理、優先度やマイルストーンの設定、実際に進捗の可視化、コードとタスクの紐付けなどが必須となります。これができないと、作業の漏れ抜けが発生し、品質にも大きな影響が出てしまいます。ここではイシューを使ってタスクを作成し、実際に変更したコードを取り込む手順を紹介します。
イシューの作成と管理
プロジェクトを開き、サイドバーから「Issues」をクリックします。イシューの一覧が標示されますので「New issue」をクリックしてください。
イシューの作成画面が開きます。まず、イシューのタイプを「Incident」「Issue」「Task」から選択します。プロジェクトにもよりますが、おおまかにIncidentはサーバートラブルなどの事件、Taskは定期メンテナンスなどの予定された作業、それ以外の様々な問題がIssue、といった使い分けをするのが一般的でしょう。今回はコードに変更を加えたいので、Issueを選択しました。
Titleにはイシューのタイトルを入力します。タイトルを見ただけでどのような内容かわかるように、やるべきことや問題点を簡潔にまとめましょう。
Descriptionには、イシューの詳細を入力します。何が問題なのか、なにをやるべきなのか、どうなったらゴールなのか、明確に記述することを心がけてください。
Assigneeは、このイシューの担当者を設定します。特定のメンバーに作業を割り振る際に設定しましょう。Labelsは、イシューにつけるラベルです。「バグ」「機能強化」「セキュリティ」といったラベルをつけることで、イシューを管理しやすくなります。Milestoneはこのイシューが属するマイルストーンです。マイルストーンを使うことで、複数のイシューをまとまったグループとして管理できます。「次のリリースに含める機能改善」などは、マイルストーンを使うと管理しやすくなるでしょう。Datesはイシューの開始日と期限を設定できます。Contactsは、このイシューに関する連絡を送る先を、個別に指定できます。Contactsについて詳しくは、ドキュメントを参照してください。
また、「This issue is confidential and should only be visible to users having at least the Planner role」にチェックを入れると、このイシューは機密扱いとなります。セキュリティインシデントのように、関係者以外の目に触れると困るイシューで設定しましょう。
「Create issue」をクリックすると、イシューが作成されます。
マージリクエストでコードレビュー
それでは、イシューを解決するためコードに変更を入れましょう。ですが、DevOpsの世界において、mainブランチに直接変更をコミットするのは御法度です。なぜなら、検証されていない変更をmainブランチに取り込むと、意図せずコードを破壊してしまう危険性があるためです。そのため、こうした機能追加や変更は、Git上で別のブランチを作ってコミットし、問題がないことを確認した上で、ブランチをマージするという戦略を取ります。GitLabには、こうしたブランチのマージを管理する機能があります。それが「マージリクエスト」です。
ブランチとマージリクエストの作成
サイドバーの「Issues」から、先ほど作成したイシューを開いてください。ここにある「Create merge request」をクリックします。
マージリクエストの対象となる、ブランチの作成ダイアログが開きます。ここでベースとなるブランチを選択し、作成するブランチ名を入力します。当然ですが、ベースとなるブランチはmainです。作成するブランチは、「feature/add_project_description」としました。ブランチの命名規則はプロジェクトごとに異なるため、ルールに沿ってわかりやすい名前をつけましょう。「test」「fix」「feature_01」のような、一見してなんの修正なのか理解しづらい名前は避けましょう。なお、一般的に機能追加は「feature/」、バグ修正は「fix/」などのプリフィックスをつけて管理することが多いようです。入力したら「Create merge request」をクリックします。
新しいマージリクエストの作成画面が開きます。Titleにはマージリクエストのタイトルを入力してください。イシュー同様、何をしようとしているのかを簡潔に書くとよいでしょう。Descriptionには、マージリクエストの詳細を記述します。イシューからマージリクエストを作成すると、デフォルトで「Closes (イシュー番号)」が入力されています。これは特殊なコメントで、このコメントを含まれるマージリクエストがマージ完了すると、自動的に指定されたイシューをクローズするためのものです。イシューとマージリクエストを関連づけられるため、ぜひ活用してください。Asignee、Milestone、Labelsなども、イシュー同様、適宜設定しましょう。また、マージリクエストにおいて大切なのはReviewerです。レビュアーは変更に対するレビューを行い、実際にマージしてよいかの判断を下すため、非常に重要な役割です。適切な担当者をアサインしてください。
設定が完了したら、ページ下部にある「Create merge request」をクリックすると、マージリクエストが作成されます。
コードの変更とコミット
これでマージリクエストと、ブランチが作成されました。それでは実際に、ブランチに変更をコミットしましょう。手元のPC上で、以下のようにブランチを切り替えます。
$ git fetch origin
$ git switch feature/add_project_descriptionこの状態でREADME.mdに変更を加えましょう。変更が完了したら、以下のようにコミットを行います。
$ git add README.md
$ git commit -m 'プロジェクトの解説を追加'続いて、変更をGitLabにPushします。以下のようにPush先のブランチを指定して、Pushを実行してください。
$ git push origin feature/add_project_description左ペインからMerge requestsを開いてください。マージリクエストの一覧が標示されますので、先ほど作成したマージリクエストを開きます。「Overview」「Commits」「Pipelines」「Changes」の4つのタブが表示されますので、Commitsをクリックしてください。そこに、以下のように先ほどPushしたコミットが追加されていれば問題ありません。
コードレビューとマージ
ブランチにコードがコミットされたら、コードレビューを行います。ここから先はレビュアーの作業となります。マージリクエストの画面を開き、Changesタブをクリックしてください。以下のように、このコミットで行われた変更差分が表示されます。
差分の内容に問題がないことが確認できたら、いよいよmainブランチへ変更をマージします。Overviewタブを開いて、「Merge」ボタンをクリックしてください。以下の画面が表示されますので「Merge」をクリックします。なおこの際「Delete source branch」にチェックを入れておくと、マージ元となるブランチ(ここではfeature/add_project_description)を削除できます。一般的に機能追加用の一時ブランチは、マージ後には不要となるため、ここで掃除してしまうのもよいでしょう。
マージが完了すると、マージリクエストのClosesコメントに従い、自動的に関連するイシューがクローズされます。
まとめ
このように、GitLabの機能を活用することで、解決すべき問題を明確にし(イシュー)、実際に変更を行い(Git)、変更が妥当かレビューした上で反映する(マージリクエスト)ことができます。もしこのような仕組みがなかったら、解決すべき問題があやふやなまま宙に浮いてしまったり、破壊的な変更をコミットしてしまうこともあるでしょう。また、今回は紹介できませんでしたが、GitLab CI/CDという仕組みも存在します。人間によるレビューは、どうしても見落しが発生してしまいます。ですが、CI/CDを利用すれば、マージリクエストの変更内容を自動的にテストすることも可能で、より品質を向上させることも可能です。
DevOpsを実践するにあたり、こうした支援ツールの存在は必要不可欠です。そしてFJcloud-VのDevOps with GitLabであれば、DevOpsの中心となるGitLabサーバーを、メンテナンスフリーで簡単に用意できます。ぜひお試しください。
