以前からCIをやってみたいと思っていて、
最近個人プロジェクトの環境が整ってきたので、
CIの環境構築をしました。
構築前の状況
- Railsアプリの作成を始めて、最小限の機能ができたところ
- ソースはgitlab.comのプライベートリポジトリで管理
- RSpecで一通りテストも作ってある
- Capistranoでproduction環境へのデプロイもできるようになった
CIサービスを選ぶ
GitHubを使っている場合は Travis CI や Circle CI が選べるのですが、
これらはGitLabとは連携できなさそうで、どうしようかと思っていたら
GitLabは独自に GitLab CI を提供しているようです。
GitLab CIにプロジェクトを登録
https://ci.gitlab.com/
GitLabのアカウントでサインインすると、ダッシュボードが表示されて
自分のプロジェクトの中からCIに登録するものが選べるようになっています。
GitLab CI Runner
プロジェクトを選んで設定を進めていくと、どうやらRunnerというのを
用意する必要があるようです。
説明文にあるリンクを辿っていくといろいろなRunnerが選べるようですが、
普通に Official GitLab Runner をパッケージでインストールすることにしました。
インストールが終わるとRunnerが自動的に起動して、
特に設定などしなくてもそのまま最後まで使えました。
ジョブの設定
プロジェクトの設定に戻ってくると、先ほどインストールしたRunnerがもう使えるようになっています。
この後は実行するジョブを指定していくわけですが、
どうも最近になって指定する方法が変わって、
以前は設定画面で直接指定していたのが、
今はリポジトリ直下に.gitlab-ci.ymlというファイルを作る方式になったようです。
このファイルの仕様についてはGitLabでもまだ検討中のようで、
ちゃんとした説明が見つからなくて困りましたが、
いろいろ試行錯誤して何となく動くものができたので、
ちゃんとした書き方になっているか自信はないですが、載せておきます。
before_script:
- ruby -v
- cp /var/rails/MyApp/shared/.env .
- cp config/database.yml.ci config/database.yml
- bundle install --path vendor/bundle
rspec:
script:
- bundle exec rake db:setup RAILS_ENV=test
- bundle exec rake spec
tags:
- ruby
- mysql
production:
script:
- bundle exec cap production deploy
tags:
- capistrano
- debian
only:
- master
その他の環境設定
-
RSpecのテストでMySQLを使うようにしているので、
Runnerの環境のMySQL用にdatabase.yml.ciを作って、
テストを始める前にdatabase.ymlにコピーするようにしました。 -
CapistranoはデプロイするときproductionサーバにSSHで接続するのですが、
Runnerからproductionサーバに接続するときにパスワード認証が発生して
デプロイがエラーになってしまったので、Runnerのアカウントがパスワード認証なしで
接続できるようにしました。