最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。

CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。

色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう！

この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools

/circleci.yml

deployment:
  feature:
    branch: /^(?!^master$).+$/
    commands:
      - ./script/staging_deploy.sh
  production:
    branch: master
    commands:
      - ./script/production_deploy.sh

/script/staging_deploy.sh

#!/bin/bash -e

STAGING_APP_PREFIX="hoge-cms"
NUM_OF_STAGING_SERVERS=4

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/staging_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

function prepare_for_staging_server() {
  heroku addons:add redistogo:nano || : # nothing if it's already installed
  heroku labs:enable user-env-compile
  heroku config:add \
      FOO=bar \
      BAZ=hoge
}

deploy

/script/production_deploy.sh (これは普通にdeployするだけのscript)

#!/bin/bash -e

HEROKU_APPS="<heroku app name1> <heroku app name2>"

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/production_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

deploy

上のスクリプト、CircleCIのheroku deployの仕組みは使っていないので、HerokuのSSH keysの登録と、 上記スクリプトから参照される HEROKU_API_TOKEN と HEROKU_USER を、CirclCIのEnvironment variablesに設定する必要ある。

って、大事だなーと思っていてエンジニアの力の差が大きく出るところだと思っている。

• 新規サービス
• 新規アプリ
• ちょっとした社内ツール
• プロジェクトの進め方の改善
• 大き目のリファクタリング

とかなんでも、とりあえず始めることは簡単だ。ただ、それを形にしてリリースしたり継続するのは難しい。

データベースのマイグレーションが必要だったり、最後の細かいUI調整もなかなか時間がかかる。色々な環境でのテストも必要だ。

技術的以外な部分でも、関係者との調整や、ユーザーへのお知らせ、面倒なことが多い。

開発者なら誰でも実感値あると思うけど「だいたいできた」から「リリース」までの距離はだいぶ遠い。自分の感覚としては「だいたいできた」で良くて半分くらい。楽しいのも最初の半分、後半は楽しくないことが多い。飽きも来る。

(これらの面倒なことを減らすのが、Quipper CTOである自分の役目だとも思っている、がそれはまた別の話)

経験値、みたいなものもリリースするとしないで10倍くらい違うと思っている。

それだけリリースは難しい。

なんか、だらだらと思ったことを書いてみた。

リリース力を鍛えよう。

(ちょっと前に pplog に書いたのを移動してみた)

前提: GitHub flow を使っていてCIサーバーはJenkins

最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。

この改善をやる前の悩み:

1. pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。
2. コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。
3. コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-requestで非開発者の人を巻き込めたらそこで気付けるのに。

これらの問題を解決するのに、feature branchもHerokuにJenkinsから自動的にデプロイするようにしたら色々幸せになれた。

具体的には、N個(N=アクティブな開発者の数くらいが良さそう)のfeature branchのテスト用のHeroku appを予め作っておいて、feature branchにpushされるたびに、Jenkinsからその中の一つへデプロイされる感じにした。

補足:

1. 同じfeature branchの新しいpushがなるべく同じHeroku appにデプロイされ続けるようにとか、heroku configもするとか、多少工夫してる。
2. 初期の頃、feature branch毎にJenkinsから毎回heroku createしてたが、それはさすがに怒られそうなので、複数をローテーションで使うようにした。
3. いまどき？だとJenkinsで動的に仮想環境とか作っちゃうのもありだと思う。でも、Herokuが楽過ぎて頑張って仮想環境作る必要もないかな、というのが現在の弊社の状況。

非開発者にもレビューして欲しいときは、pull-request上でmentionして、heroku上のデプロイされたものを見てもらう感じ。基本的にUIに変更のあるようなものは非開発者もチームほぼ全員見るようにしている。

数ヶ月運用してるけど、もうこれなしでは生きるのが辛い感じにまでなってきてる。

非開発者の人もとても楽になった感じで、それまでは、色々な変更が入った(または肝心なものがコミュニケーションの問題で入っていない)masterブランチが動作しているのを見るしかなく「何が」実際変更されたのかわかりづらかったが、このフローにしてから、変更点がわかりやすく開発者とのコミュニケーションもだいぶ楽になった。また、チームメンバーの誰かが「思ってもみなかった」変更がいきなり入ってしまうということもなく、だいぶストレスが減った感じ。

また、開発者も、それまでは、merge後、非開発者に指摘されると「めんどくせーなー」という意識が生まれがちで、かつ、その場合mergeから時間が経っていることも多く、その変更に対するフレッシュさが減り、再度作業を始めるまでの心理的な負担(実際、実装を思い出すための脳のコストも高そう)も高かった。それが、pull-request中に非開発者からフィードバックが貰えることで、そのpull-requestにcommitを追加することだけでさくっと修正できて、全体のスピード感がとてもあがったし、開発者の負担も減った。

つまり、pull-requestのmergedがチームメンバー全員にとってのDONEというステータスになり「実装終わったけどまだ本番には入っていない」とか「チームメンバーが納得してないものが本番に入っちゃった」みたいな事故/ストレスを減らせた。Done means DONE!

これらの結果、masterにmerge後、Jenkinsからの自動デプロイもかなり安心してできるようになった。

おまけ:

@hsbtさんが いい感じのGitHub flowベースのワークフローをあげていたので、弊社(Quipper)との差分を書いてみる。

1. masterブランチは常にデプロイ可能な状態でかつ自動デプロイされている。
2. なので、手でデプロイという作業は発生しない。
3. WIPのpull-requestはそれほど推奨してない。この辺はpull-requestの粒度の話もあるので別エントリで書きたい感じ。
4. 関連して、チェックリストみたいのも基本作らない(必要ない)。
5. mergeはレビューした人が行う。
6. コードレビュー以外のテストも上に書いたように、feature branchでしてしまう。
7. インフラメンバーいない。(が、そろそろ欲しい！ 興味ある人ご一報を)。
8. Release’s notes 作成してない。

フローの中でGithub(とJenkins)の外へ出たくない、という方針。

この辺りって、絶対的に正しい方法というのはなく、組織のサイズとかサービスの規模に応じて、ダイナミックに変えていくのが正しい道だと思っている。

追記: CircleCIで上記のことをする方法書いた

Quipper、日本オフィスができて半年以上達ち、このブログでも改めて色々発信してみようと思ってはいるのだけど、一度間が空いてしまったブログの再開はなかなか難しい(本人以外誰も気にしていない現実を知りつつ)。この状況を打破するために、軽いのをまず書いてみる。本当はQuipperの開発について色々書きたいんだけど、それはまた次回。

最近出会った mailtrap.io というサービスがWebシステム開発にとてもいい感じなので紹介してみる。

メール送信は、ある程度テストを自動化したとしても、繰り返し、手で実行して目で確認することも多い。テストするときは、送信先アドレスを自分にして、送信して、自分のメールボックスを開いて確認する、とか。めんどくさい。何か問題を発見したら、関係者にメールをフォワード、とかもめんどくさい。ステージング環境では実際に送らずに、ログに出すという方法もあるけど、これだと、開発者ではない人には使いにくい。開発者であっても、何か問題があったら、それをコピペして、issue管理システムに貼る、とかめんどくさい上にレイアウトも崩れがち。

この mailtrap.io というサービスでは、これらのめんどくささからある程度解放してくれる。このサービスは "Fake SMTP server for development teams to test" と書いてあるまんまで、SMTPサーバのように動くのだけど、実際にはメールを送信せずにそのサービスに溜まっていき、送ったメールの内容をWeb UIから見ることができるサービス。

Quipperでも、ステージングサーバーに入れて使っている。実際に使ってみると使い勝手がかなり良くて、

1. 一通一通にpermanent linkができるので、issue管理システムとかチャットとかで、共有しやすい。
2. HTMLメールとかも普通に見える。
3. 貯めてある状態からワンクリックでメールを実際に送信することもできる。「実際のメールソフトで見てみたい」というときにも便利に使える。
4. どんな 宛先(to)でも送ることができるので、テスト環境で作った適当なデータでもちゃんとメールの送信のテストができる。
5. UIがとても簡単。Gmailみたいな感じで誰にでも簡単に使える。ステージング環境でテストするのは開発者だけではないので、誰でも簡単に使えるというのはとても重要。

などなど。

設定方法は、単純にSMTPの口が提供されるだけなので、それを設定するだけ。Quipperでは、Railsアプリには config/initializers/mailtrap.rb みたいのを置いている。 (herokuを主に使っているので、設定はENV経由)

if ENV['MAILTRAP_HOST'].present?

   ActionMailer::Base.smtp_settings = {
     address:              ENV['MAILTRAP_HOST'],
     authentication:       :plain,
     enable_starttls_auto: true,
     password:             ENV['MAILTRAP_PASSWORD'],
     port:                 ENV['MAILTRAP_PORT'],
     user_name:            ENV['MAILTRAP_USER_NAME'],
   }

   Mail.defaults do
     delivery_method :smtp, ActionMailer::Base.smtp_settings
   end

 end

このサービス、今のところ無料。「メインのビジネスじゃないから」らしい。

このブログは「何か書きたい」というのと「色々試したい」という欲求を満たすために今年の一月に始めたわけだけど、その「試したい」ことの一つが「はてなブックマーク(以下はてブ)」だった。

自分自身はブックマークとしては delicious を使っているのだけど、はてブもRSSで人気エントリのものはなんとなく読んでいるし、twitterでも、はてブが元の話題がそれなりに流れているし、影響力がそれなりに強いように思う。

それで、 前回の記事 に、たくさんのはてブを頂いたので、ちょっとアクセス数を出してみる。

また、同じように、今、旬なtwitterからのアクセス数も出してみる。タイトルの"761 ツイート"ってのは、twitter公式の Tweet Button で表示されてる数。

visitor数 (Google Analytics調べ)

記事を投稿したのが19日で、普段のvisitor数が数百なので、どかーんと増えてだいたい丸3日で正常運転に戻ったようだ。ほとんどが、はてなブックマークのトップページ(人気エントリ)と、はてなのトップという掲載期間のあるものだから当然か。

twitterは自分が想像していたよりも息が短く、同じように丸3日ぐらいでブログへのアクセスもほとんどなくなり、自分宛のmentionもほとんどなくなった。もちろん、記事の内容や質によってはもっと後を引くこともあるんだろう。

もちろん、リファラーからの分析なので、専用クライントとか、RSSリーダからのものは入ってない。特にtwitterはそういうのが多そうだなあ、と想像はできる。

数字的には、正直なところ、まあこんなものか、という感じ。もう数倍くらい多いのかなと勝手に妄想していた。

ええ、普段はB2BのWebのお仕事なのであまりこの辺の分析をしたことがない。そろそろ勉強しないとね。

おまけ – そのアクセスによって：

followers/subscribersの増加

• twitterのfollowerが+100
• Google Readerのsubscribersが+116
• livedoor Readerのsubscribersが+53

ネットワーク使用量: 1.85GB

このブログで使ってるVPS の契約は月間100GBなんでしばらく平気そう。

はてブのコメントへの感想

コメント は基本的に「共感できる」と「勉強になる」とが大部分だった。感想文/反省文なんで、あんまり叩かれることもなく静かだった。

IE6だと化けるよ、について

直した。content-typeのヘッダーにtypoがあったorz

IE/Firefox/Chrome/Safari/Opera/w3m 辺りの最新版ではたまに確認しているのだけど、IE6とかもう仕事だけで勘弁してよ！ ってのはある。

また、このブログでのIE6は、通常時で0.7%くらい。今回の一時的にアクセスが多かったときで1%ぐらい。こういうブログでまだ1%弱いるってのはほんと驚き。

それでは、静かに戻ったこのブログを今後もよろしくー。