GitHub + CircleCI + Capistrano + Slack + Hubotな環境を作るのに苦労したお話

普段の開発はCircleCIを利用しています。
そして、デプロイにはCapistrano3を利用しています。

普段は僕はSymfonyでの開発が多くて、過去にCapistrano3でSymfony2をデプロイするなんて記事を書いたりもしています。

さて今回はSymfony2なアプリで「GitHub + CircleCI + Capistrano + Slack + Hubot」な環境を作った時に苦労したポイントをまとめてみました。なお、今回はGitHub + CircleCI + Capistrano + Slack + Hubot で快適リリース生活の記事を元にCircleCIからCapistrano3を使ってデプロイしました。詳しい設定はそちらの記事を参照してください。

ハマった箇所

幾つかハマりました・・・。英語が読めないのも弱点なので、もう少し英語勉強したいです。

CircleCI+Capistranoでハマった箇所

Rubyのバージョン問題
SSH keyどこに置くんですか？
Symfony3だった問題・・・

Slack+Hubotでハマった箇所

リリースブランチを作成してなかった
テンプレートファイルが見つからない
hubotがforeverしない

CircleCI+Capistranoでハマった箇所

Rubyのバージョン問題

普段Rubyを使わない僕は、CircleCIのデフォルトのバージョンでCapistrano動くだろうと高をくくっていたのですが、どうやらだめでした。 net-sshがbundlerでエラーになってしまいました。どうやらRuby2.0.0以降じゃないとだめみたいなんですね。https://git.io/voGWd デフォルトのバージョンなにか知りませんが、Rubyのバージョン指定して入れましょう。

1
2
3
4
5
6


vi circle.yml

machine:

  ruby:
    version: 2.2.2

SSH keyどこに置くんですか？

GitHub + CircleCI + Capistrano + Slack + Hubot で快適リリース生活の記事だとCAP_PRIVATE_KEY でSSH keyのパスを指定してるんですが、キーどうすればいいのか・・・って悩んでました。

プライベートなキーだし、gitのリポジトリに含めるのは流石に嫌なわけですよ。。よくドキュメント読んでいたら、SSH PermissionでSSHキーを登録出来る事がわかりました。（そんぐらい知っておけよってツッコミはやめてください）

さて、この登録したキーはどこから参照できるのか。
調べたら~/.ssh/の下にありました。

ということは普通にCAP_PRIVATE_KEYは~/.ssh/以下のキーを指定すればいいんですが、どうやら名前はid_{hostname}みたいな形になっているようです。登録したhostnameによって変わるぽいです。詳しくはCircleCIにSSHで接続して確認してみましょう。

Symfony3だった問題・・・

ここまでの設定は完璧なのになぜかSymfonyのcache:clearコマンドが実行されるタイミングでエラーになってました。
設定は完璧なはずなのにおかしい・・・とおもったらどうやらcapistrano/symfonyは明示的にSymfonyのバージョンを指定してあげないとSymfony3としてコマンドが実行されるようです。

皆さんご存知だとは思いますがSymfony3からはapp/consoleがbin/consoleに変わっているわけなんですね。 Symfony2だと当然コマンドが無いのでエラー起こして終わるわけです。ということで明示的にSymfonyのバージョンが2であると指定しましょう。

1
2
3


vi deploy.rb

set :symfony_directory_structure, 2

Slack+Hubotでハマった箇所

リリースブランチを作成してなかった

いつもmasterブランチがdeploy対象だったのですが、今回はreleaseブランチを本番にデプロイするためのブランチという運用ルールを決めたのですが、、、
github上にリリースブランチをpushし忘れててエラー起こしてました。

ただ、原因の特定するのは苦労しました。これはhubotからのレスポンスのエラーメッセージが「Error: Cannot call method ‘match’ of undefined」としか返ってこなかったためです。

テンプレートファイルが見つからない

hubot-github-pr-release用のテンプレートを用意していたのですが、いつもundefinedと言われてしまう現象がおきてました。

こんな感じのやつ。

PR自体は作成されていたので問題ないといえばないんですが、やっぱ辛いですよね。
これはテンプレートファイルに無駄な改行があったのでそれが問題だったようです。

hubotがforeverしない

これはちょっと別の話かもしれませんが、herokuだとあれなんでついでにhubotをVPSで動かすように切り替えました。
foreverでデーモン化しようと思ったらうまく行きませんでした。

これは結局のところcoffieescriptがグローバルにインストールされてなかっただけだったので、npm install -g coffeescriptでかいけつできました。

なぜこのタイミングでデプロイを自動化するのか？

今回まだまだリリースは先のプロジェクトでしたが、あえて先にデプロイ環境を用意しました。これは@ksetaさんがプロジェクト開始時にデプロイ環境まで用意するという話を聞いて刺激をうけて用意しました。

プロジェクト始まるタイミングでCIまでは準備していましたが、デプロイまで準備するほうが後々ラクになるしいいですね。
それにQA環境とかdev環境へのデプロイまでも自動化できるしなかなか良いと思いました。

あとは開発中のブランチも手軽にCI経由でデプロイして簡単に確認できる環境作れたらいいのですが・・・そこはちょと難しいそうなので、先駆者募集しています。

今後の課題

ある程度モダンな環境でも問題はあるんですよね。

ロールバックどするの？

うーんデプロイ時にリリースするのはいんだけど、どうやって　Capistranoのロールバックをするのか・・・。いい感じの方法知ってる人は教えて下さい。

踏み台サーバがあるような本番環境でのデプロイ

Capistranoでデプロイする際に本番サーバに直接sshで繋げない場合はどうしたらいいんですかね？ AWS環境下ならCircleCIからCapistranoを利用してAWS（EC2）にデプロイするとかで書かれてる方法でいけるとは思いますが。

Capistranoでプロキシする方法は今度調べてみます。

まとめ

CirlceCI+Capistrano3でのデプロイは世界が変わるのでぜひぜひ試してみてください。