はじめに
先日「GitHub実践入門 ~Pull Requestによる開発の変革」という書籍が発売されました。この書籍の副題にある通り、Pull Request による開発は従来のものとは一線を画す、非常に画期的なものです。
この Pull Request による開発フローを、ソースコードを開示できない業務システムの開発に適用したい場合、いくつかの選択肢があります。
Bitbucket などのサービスもありますが、無料で利用する場合はユーザ数が 5 名までなどの制限があります。
そもそも業務システムのソースコードをホスティングサービスにアップロードすること自体が許されない場合もあるでしょう。この場合、GitHub Enterprise か GitLab, GitBucket のいずれかを利用することになりますが、GitHub Enterprise はそれなりに高価なので、ここでは無料の OSS クローンを利用することにします。
GitBucket のインストールは自動化するご利益を感じられないほど簡単なので、今回は Ansible を使って GitLab をインストールし、以下の構成で動作させる手順を紹介します。
- Git 1.8
- Ruby 2.1.0
- MySQL
- Nginx + SSL (自己署名証明書)
なお、GitLab では Pull Request を Merge Request と呼びますが、実現している機能は同じです。
前提
以下の手順に従って仮想環境を構築しているものとします。
以下、上記手順に従って構築した仮想環境を作業マシン、gitlab を構築する環境を対象マシンと呼びます。
手順
対象マシンの準備
まず対象マシンを用意します。すでに対象マシンが存在する場合、この手順は不要です。
Windows 上に Vagrant で対象マシンを用意したところ、リソース不足のためか bundle install で不定期に失敗したため、ここでは Microsoft Azure 上に 2 コアの CentOS 6.5 を用意しました。Azure 上で Linux を動作させる手順は、下記を参照してください。
鍵交換
対象マシンに一般ユーザでログインし、~/.ssh/authorized_keys が適切なパーミッションで存在することを確認します。
# vagrant at precise64 in ~ [16:20:13]
$ ssh username@xxx.xxx.xxx.xxx
username@xxx.xxx.xxx.xxx's password:
存在しない場合は下記のようにして作成します。
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh/
$ touch ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
~/.ssh/authorized_keys が適切なパーミッションで存在することを確認したら、proxy 環境化の CentOS に Ansible で Redmine をインストール - Qiita を参照して、作業マシンの公開鍵を対象マシンに登録します。
SELinux 停止
SELinux が有効になっていると Ansible から root 権限で作業できないため、SELinux を無効にします。
$ sudo vi /etc/sysconfig/selinux
$ sudo cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
SELinux を無効にしたら対象マシンを再起動します。
プロビジョニング
以下のようにして作業マシンに playbook を clone します。
# vagrant at precise64 in ~ [16:38:52]
$ g clone https://github.com/garbagetown/ansible-gitlab.git
Cloning into 'ansible-gitlab'...
remote: Reusing existing pack: 204, done.
remote: Total 204 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (204/204), 18.54 KiB, done.
Resolving deltas: 100% (63/63), done.
clone したディレクトリに移動し、対象マシンの情報を設定します。xxx.xxx.xxx.xxx は自身の環境に読み替えてください。
# vagrant at precise64 in ~ [16:39:13]
$ ansible-gitlab
# vagrant at precise64 in ~/ansible-gitlab on git:master o [16:40:25]
$ vi hosts
# vagrant at precise64 in ~/ansible-gitlab on git:master x [16:42:11]
$ cat hosts
[gitlab]
xxx.xxx.xxx.xxx
# vagrant at precise64 in ~/ansible-gitlab on git:master x [16:40:49]
$ vi group_vars/all
# vagrant at precise64 in ~/ansible-gitlab on git:master x [16:42:23]
$ cat group_vars/all
fqdn: xxx.xxx.xxx.xxx
(snip)
最後に playbook を実行します。環境にも依りますが、30 分以上は掛かるので注意してください。
# vagrant at precise64 in ~/ansible-gitlab on git:master x [16:42:29]
$ ansible-playbook -i hosts site.yml
PLAY [install gitlab] *********************************************************
GATHERING FACTS ***************************************************************
ok: [xxx.xxx.xxx.xxx]
(snip)
TASK: [nginx | chkconfig nginx on] ********************************************
changed: [xxx.xxx.xxx.xxx]
PLAY RECAP ********************************************************************
xxx.xxx.xxx.xxx : ok=58 changed=56 unreachable=0 failed=0
確認
プロビジョニングが正常に完了したら、ブラウザから https://xxx.xxx.xxx.xxx にアクセスします。自己署名証明書を使用しているため警告画面が表示されます。警告内容をよく読んで、問題なければ「このまま続行」をクリックします。
GitLab の画面が表示されたら admin@local.host と 5iveL!fe でログインします。
初回アクセスのためパスワード変更画面に遷移します。任意のパスワードに変更すると再度ログイン画面に戻されるので、変更後のパスワードでログインできることを確認します。
以上で GitLab のインストールは完了です。GitLab 自体の使い方については、下記リンクなどが参考になるでしょう。
まとめ
以上のように、とても簡単な手順で GitLab を構築することができました。
GitLab を単なるチケット管理システムのように利用することもできますが、やはり Merge Request による開発フローを採用したときにその真価を発揮します。
また、自動化された単体テスト、結合テストや、Jenkins などの CI 環境と組み合わせることで、コードベースはさらに堅牢に守られ、高い品質を保ち続けることができるようになります。
表計算ソフトによる課題管理、属人的なコードレビュー、人海戦術に依るくり返しテストなどから脱却する材料は整いつつあります。採用を検討する価値は充分にあると思います。