みなさん初めまして、@yudoufu です。 クロコスのCTO室というところで、主にインフラ & ミドルウェア & 開発プラットフォームと社内システム的なことを担当してます。

最近筆不精なもので、入社以来「いつブログを書くんだ」というプレッシャーを周囲から受け続ていたたわけですが、1年と2ヶ月にしてついに

こんなものが登場し、日々botにせっつかれるように。。。ヽ(´Д`；)ﾉｱｩ… (see: http://qiita.com/sotarok/items/b3d6fc80407f8128af0d)

というわけで、心を決めてエンジニアブログを書くことにしました。

前置き

さて、自分からはCrocosのプラットフォームについてご紹介したいと思います。

全体的なインフラについては、@sotarokが以前 Crocos を支える技術 の中で概要を紹介していました。

もちろんアップデートも色々あるのですが、同じ紹介をしても面白く無いので、今回は少し視点を変えて開発・リリースフローやテスト環境などについて紹介したいと思います。

開発 〜 リリースに至るまでのフロー

クロコスの開発は、基本的には@sotarokが開発したgit dailyを利用したフローになっています。 ざっくりまとめると、以下の様な流れです。

• 開発時には、最新のdevelop ブランチからfeatureブランチを切る
• リリースの目処がたったら、feature/xxxxxブランチ単位でdevelopブランチへのPull Request(以下、PR)を出す
• PRに対してレビュアーがレビューを行い、OKがでたらdevelopにmergeする
  • クロコスでは、OKの際には:+1:を付けることになっています。
  • 
• developへPR mergeが走ると、そこからreleaseブランチが作られ、staging -> production へと順次デプロイされる
• 最終的にリリースが完了した差分がmasterにmergeされる

Gitベースの開発フローが多く語られるようになった最近では、わりと一般的なフローになっていると思います。

PRレビューの際にはTrelloのGitHub連携を使っていて、誰がどれくらいレビューを持っていて、今どのPRがどういうステータスかを管理しています。

:+1:の付いたPRをdevelopにmergeすると、WebHook経由でリリースの概要通知と共に、自動デプロイが走ります。

このへんの自動デプロイ等については、機会があれば取り上げたいと思います。

2種類の継続テスト

CI用にJenkinsが動いていて、大きく2種類の継続テストが常時実行されています。

メインとなるdevelop/masterブランチに対するテスト

JenkinsのGit Pluginを使って、常に最新の状態をテストしています。 フローの中では、developにPRからのmergeが走った場合になりますが、機能的にはリリースと連動していません。

下記のPR単位のテストのお陰でFAILが少ないのと、だいたいproductionリリース前までにテスト結果が出るので、 問題がでたらリリースを一旦停止する、という対応を取っています。

各PullRequestごとのfeatureブランチに対するテスト

これにはGitHub PullRequest Builder Pluginを利用してテストしています。 個別のcommitに対して以下のようにチェックが走り、

これらが全て通ると、GitHubのmergeボタンにAll is wellとコメントが付いて、問題なくmerge出来ることがわかります。

テストが通っていないものは、基本的にレビューされません。 developにmergeされるものはテストが通っているもの、という保証がつくので、mergeする側としてもわりと気持ちが楽になります。

ちなみにこのPluginは、PR内のコメントをフックして特定のキーワードでテスト再実行する機能があり、クロコスのJenkinsは(おやじ|おじさん|おっさん)をキーワードにしています。

あ、ちなみにこのスクリーンショットはGitHub障害時のもので、普段は1回呼べば再実行されます。おっさんはちゃんと頑張ってますよ。

DBミラーを利用したクエリテスト

CI的なソースコードへのテスト以外にも、必要に応じてDBへのクエリテストも実施しています。

クロコスのサービスインフラは全てAWSに乗っていて、DBにもRDSのMySQLインスタンスを利用しています。

RDBMSでサービス運用を行っていれば、当然DBのschema変更が必要になってくるタイミングがあります。 また、直接DBに対してイレギュラーな調査クエリを投げる必要が出ることもあります。

ただ、大きなテーブルへの変更や大きめのクエリを使う場合などには、本番DBにいきなり実行すると長時間のロックが掛かったりしてサービスへ影響してしまう危険があります。とはいえテストDBだと規模感がつかめません。

そこでクロコスでは、本番DBのミラーDBをワンショットで作ってくれる RDS TestRunner というツールを作り、実行時間を計測して影響度を計測テストするようにしています。

RDS TestRunnerはシンプルなshellscriptで、RDSの最新のAutomated Snapshotを元にして本番のミラーを構築し、クエリを投入して実行時間を計測してくれます。

実行イメージとしては

% ./rds-testrunner.sh open -q <queryfile>

とすると、自動的にDBのミラーを作成してクエリを実行、時間を計測します。

これ自体の実行時間は、インスタンスの起動とrestore、InnoDBのWarmUpを行った上でクエリが実行されるのでそこそこ時間のかかるツールですが、完了するとHipChat上に通知するようにしているので、動作させたら後は放置できて便利です。

これによって本番への影響が数値として明確になるので、それを元にメンテの要不要、停止時間などを見積もってサービスへの影響が極力小さくなるように運用しています。

また、これをすることでクエリ自体も本番データでほぼ確実に成功する事がテストされるので、安心して本番適用できます。

おわりに

リリースフローと、その間に利用されるテストについて簡単に紹介しました。

ありきたりの話も多かったかもしれませんが、DBのクエリテストなどはRDSサマサマでものすごく実験コストが低く済み、クラウドの使い方としては良い仕組みかなと思っています。

まだまだ紹介できていないところもありますが、このくらいの話でも何かみなさんの参考になるところあれば、筆無精が頑張った甲斐があるので、ぜひぜひコメントなどいただければ幸いです＼(^o^)／