TravisCIを使ってHerokuへ自動デプロイする

前回のエントリで RubotyをHerokuにデプロイして、Slackで動かすについてまとめました。

今回はGitHubのリポジトリを変更した際に、TravisCIを使ってGitHubに変更があったときに自動でHerokuへデプロイされるようにしたいと思います。この手のお話は結構エントリがあるので、今更感もありますが、自分的に整理しておきたいので技忘録。

f:id:kentana20:20141103210518p:plain

前提・準備

デプロイするアプリケーション

ruboty-templateをForkしたリポジトリをデプロイ対象とします
TravisCIへのSign Upは完了しているものとします
- TravisへのSign UpはGitHubアカウントを使うことができます

TravisCIの設定

該当リポジトリをTravisCIの実行対象にする

TravisCIにログインしたら、Accountsメニューから該当リポジトリのスライダーをonに変更します

f:id:kentana20:20141103204414p:plain

travis gem のインストール

GitHubとTravisCIを連携するためのファイルとして .travis.yml を作る必要があるのですが、TravisCI周りの設定をCUIからいい感じにできるGemがあるので利用します

$ gem install travis

.travis.ymlの作成

ローカルにCloneしたリポジトリルートへ移動して、以下のコマンドを実行します

$ travis init
Shell completion not installed. Would you like to like to install it now? |y| y
Detected repository as kentana20/ruboty-template, is this correct? |yes| yes
Main programming language used: |Ruby| Ruby
.travis.yml file created!

これで、 .travis.yml が作成されます。Credentialのエラーが出た場合は travis login —auto コマンドを実行して認証をしてから再度実行してみてください。travis report を実行するとエラーの詳細が確認できます。

.travis.ymlにHerokuの設定を追加する

今度は作成した .travis.yml にHerokuの設定を追加します。これもtravis gemの機能を利用してCUIで行います

$ travis setup heroku
Heroku application name: |ruboty-template| $heroku_app_name
Deploy only from kentana20/ruboty-template? |yes| yes
Encrypt API key? |yes| yes

Heroku application nameはHeroku上のアプリケーション名を入力します。これで、 .travis.yml にHerokuの設定が追加されます。出来上がったファイルは以下。

language: ruby
rvm:
- 2.0.0
deploy:
  provider: heroku
  api_key:
    secure:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  app: $heroku_app_name
  on:
    repo: kentana20/ruboty-template

設定ファイルができたらGitHubへpushしておきます。

$ git push origin master

これでTravisCIの設定は完了です。

動作確認

Pull RequestでTravisCI

まずはmasterブランチから別のブランチへ作業ブランチを切り替えて、何らかの作業をします。今回は単なる bundle update でGemfile.lockを更新してPull Requestを作成します

$ bundle update
$ git add .
$ git commit -m “gem update”
$ git push origin f/bundle_update

GitHubでPull Requestを作成すると、以下のようにコミットしたリビジョンに対してTravisCIが走り、実行結果をGitHub上で見ることができます。

f:id:kentana20:20141103204529p:plain

これで、master merge前にCIを走らせて、masterに毒が仕込まれるのを防ぐことができます。また、このときのCIジョブはPull Request起因なので、Herokuへのデプロイは行っていません。

f:id:kentana20:20141103204544j:plain

master mergeでTravisCI

先ほどのPull Requestをmergeすると、もう1度TravisCIが動いて、今度はHerokuへのデプロイも実行されます。

f:id:kentana20:20141103204612j:plain

これで、前回のエントリで紹介したHerokuへのデプロイ git push heroku master をすることなく、masterにmergeするだけで、Herokuへのデプロイが完了します。便利ですね〜。

所感

Travis Gem超便利
- Travis Gem、今まで知らなかったので手動で .travis.yml 作ってましたが、これは使わない手はないですね。便利です。Herokuの設定に関してはAPI KeyのEncryptもやってくれるし、スグレモノです。
TravisCIはちょっと遅い
- TravisCIは変更を検知してからの実行が気持ち遅いかな、と感じます。無料版なので贅沢は言えないですが、もう少しサクサク動くことを期待したいです。
master mergeからの自動デプロイはラク
- 会社でも少しは自動化していますが、やはりmaster mergeをフックにデプロイができると良いですね。デプロイ運用に関わっているメンバーの心理的負担も減らせますし、お決まりの作業はどんどん自動化するべきだと強く感じます。
コミットリビジョン毎にTravisの実行結果が見られるのも良い
- リビジョン単位でCIを走らせることで「このPull RequestはCIが通っている」と一目でわかるので、安心してmergeができてこれも心理的負担を軽くできます。メンバーの人数やCIジョブのボリュームによっては「CI待ち」みたいな状態を作りかねないので注意が必要ですが、スピードアップを目指せば良いわけで、これも会社のスタンダードにしていきたいです。
ブランチ毎にデプロイ先を分けて運用なども
- 参考にしたOnishiさんのエントリにもありましたが、devブランチはStaging環境へ、masterブランチはProduction環境へデプロイする、みたいな設定を作っておけば、どちらもデプロイを自動化できて非常にラクにデプロイ運用を行う事ができてTravis便利だと思いました。
CircleCIはどうなんだろう
- 最近はCircleCIの方が流行りっぽいので、今後はCircleCIも試してみたいと思いました。
ForkしたリポジトリはPull Requestの送り先に注意
- 完全に本題とは外れますが、個人的な反省の意味を込めて。今回のデプロイ対象リポジトリはid:r7kamuraさんのリポジトリをForkしてるんで、Pull Requestの送り先を間違えるとFork元に飛んでしまいます。今回は実際にPull Requestを飛ばしてしまって「間違ってるよ」と指摘をいただいてしまいました。。反省です。