GitLab運用ベストプラクティス

個人的ベストプラクティスです.
GitLab運用に関していろいろ記載しました.

↓↓↓GitLabのオンプレミスを構築に関してはこちらをご覧ください↓↓↓

目次

オンプレミス vs クラウド

クラウド版SaasであるGitLab.com(以降GitLab.com)とオンプレミス構築したGitLab EE(CE)(以降オンプレミスGitLab)を比較します.

GitLab.comは,無料版と有料版が存在します.無料版は機能制限が存在します.

Saasとは,「Software as a Service」の略で,クラウドサービスとその保守を行うサービスです.メリットは,ソフトウェアの管理をSaaS提供元に一任できることで,導入が簡単です.デメリットは運用コストが継続的にかかってしまいます.

リポジトリ管理を目的とする場合はGitLab.comでも十分ですが,GitLabの最大の強みともいえるCI/CDに実行時間制限がかかってしまします.

多少構築の手間はかかってしまいますが,オンプレミスGitLabを使用することを推奨します

さらに,オンプレミス構築にDockerを用いることでサーバ移行の手間を軽減できます

GitLabオンプレミス構築

↓↓↓GitLabのオンプレミス構築に関してはこちらの記事を参照ください.↓↓↓

GitLab構築後すぐに設定すること

とりあえずGitLabを導入したけど,この後どうしたらいいの?

セキュリティ関係

・プロジェクトを作成可能な権限を制限(Maintainersのみ作成可能)

  1. [Menu] > [Admin] を選択
  2. [Settings] > [General]を選択
  3. [Visibility and access controls] > [Default project creation protection]を[Maintainers]に設定
  4. [Save changes]をクリックし,保存

・アカウントの作成権限を変更(管理者の承認を必須とする)

  1. [Menu] > [Admin] を選択
  2. [Settings] > [General]を選択
  3. [Sign-up restrictions] > [Sign-up enabled]のチェックを外す
  4. [Sign-up restrictions] >[Require admin approval for new sign-ups]のチェックを入れる
  5. [Sign-up restrictions] > [Send confirmation email on sign-up]のチェックを入れる
  6. [Save changes]をクリックし,保存

ユーザ名を変更

特権管理者の初期ユーザ名はrootです.

rootは他者から推測されやすいため,ユーザ名,アカウント名を変更します.

・ユーザ名変更

  1. トップバー右のアバターアイコンをクリックし,[Edit Profile]を選択
  2. [User Setting] > [Account]を選択
  3. [Change username] でrootからアカウント名を変更
  4. [Update username]をクリックし,保存

・アカウント名変更

  1. トップバー右のアバターアイコンをクリックし,[Edit Profile]を選択
  2. [User Setting] > [Profile]を選択
  3. [Main Setting] > [Full name]を変更
  4. [Update profile settings]をクリックし,保存

パスワードの変更

  1. トップバー右のアバターアイコンをクリックし,[Edit Profile]を選択
  2. [User Setting] > [Password]を選択
  3. パスワード変更し,[Save password]をクリックし,保存

二段階認証について

オンプレということもあり,私の環境では不要と考えており,導入していません.

ある程度セキュリティが担保されていることと運用時の二段階認証の手間の方がかかるとの判断しました.

プロジェクト作成後にすぐに設定すること

デフォルトブランチの変更

後述するGit Flow運用を行う場合は,デフォルトブランチをmain(master)からdevelopに変更します.

ブランチの保護

不用意なPushを禁止(重要度:高

開発ブランチやリリースブランチに直接Pushされることを防ぎます.

  1. [Setting] > [Repository]
  2. [Protected branches]にて,”main”や”develop”ブランチに対して,[Allowed to push]を[No one]に設定
  3. [Save changes]をクリックし,保存

自動テストを必ず実行する(重要度:高

自動テスト(CI)を行っていないブランチのマージを防ぐ設定を行います.

  1. [Setting] > [General] を選択
  2. [Merge requests] > [Merge checks]の[Pipelines must succeed]と[All discussions must be resolved]をチェック

Merge commitの設定

  1. Merge commit
  2. Merge commit with semi-linear history
  3. Fast-forward merge

テストの安全性を考えると,2か3に設定することをお勧めします.

プロジェクトの運用

Git Flow

プロジェクト運用にあたり,リポジトリの運用方法は多くの試行錯誤がなされてきました.

バージョン管理システムとして,CVSやSVN,Gitという歴史的な流れがありますが,その時代ごとに様々な運用方法が提案されてきました.

Gitにおいては,その運用方法(Workflow)としてGit Flowが有名です.

Git Flowが必ずしも最適な運用とは限りませが,自己流で運用を行うよりも,すでに実績のある採用すべきです.

CI/CD

CI/CDにおいて,Docker in Dockerを使用します.

少し設定が面倒ですが,Docker in Dockerを使用することで,ホストとの分離性や独立性をより高めます.

よかったらシェアしてね!
目次