FacebookのCIのはなし

「Facebookには、テストサーバが存在しない。すべての開発者は本番サーバで直接開発・リリースしている。」という話があるようですが、少なくとも開発者ならこの話を文面通りに受け取る人はいないはずで、CIでバッチリ管理してるだろうということで、少し調べてみた。


まず、

• http://www.quora.com/What-kind-of-automated-testing-does-Facebook-do
• For our PHP code, we have a suite of a few thousand test classes using the PHPUnit framework. They range in complexity from simple true unit tests to large-scale integration tests that hit our production backend services. The PHPUnit tests are run both by developers as part of their workflow and continuously by an automated test runner on dedicated hardware. Our developer tools automatically use code coverage data to run tests that cover the outstanding edits in a developer sandbox, and a report of test results is automatically included in our code review tool when a patch is submitted for review.
• For browser-based testing of our Web code, we use the Watir framework. We have Watir tests covering a range of the site's functionality, particularly focused on privacy there are tons of "user X posts item Y and it should/shouldn't be visible to user Z" tests at the browser level. (Those privacy rules are, of course, also tested at a lower level, but the privacy implementation being rock-solid is a critical priority and warrants redundant test coverage.)

テストちゃんとやってますよ、と。

Watirてのは初めて聞いた。こんどドキュメント見てみよう。

そして、

• http://framethink.blogspot.com/2011/01/how-facebook-ships-code.html
• ops team runs code releases by gradually rolling code out
• facebook has around 60,000 servers
• there are 9 concentric levels for rolling out new code
• [CORRECTION thx epriest] "The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc."
• the smallest level is only 6 servers
• e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
• if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
• so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.

最小レベルはサーバ６台構成。概念が違うだけで、p1=テスト、p2=ステージング、p3=本番　でした。

サーバ多くなってくると、いろいろな工夫が必要になってくるね！

かねこ(・ε・)

おさらい（１）ソフトウェア内部アーキテクチャ

さて、勢いにのってガリガリとコードを書きたかったのですが、そんな時間はありませんでした。

なので、そういえば書きたかったシステムの設計について書いてみようと思います。

だいいちだん、ソフトウェア内部構造のまき。

ちなみにこれは、某Challenging Tomorrow's Changesな会社のSFAシステム構築プロジェクトに僕とまっちゃんコンビで参画したときに、お師匠のたなかみつるさんに教えてもらったアーキテクチャで、わずか数ヶ月の間にみにつけたこの設計技法は、その後何年間もずーっと、僕のシステム設計思想のベースになっているものです。ありがとう、お師匠。げんきか、まっちゃん。

というわけで、絵をかいてみました。

• N層アーキテクチャは導入必須。層を分離しないとテストコードが書けない。
• テストコード必須。テストコード書かないと、機能追加の際に一定ライン以上の品質を保証することができません。あと、漠然とした不安につきまとわれます。
• 基本的にMVCパターンの適用は必須で、要件と複雑さに応じて層を設計します。上の図は中間規模の業務システムを構築するときに設計のベースとしているMVC+Serviceでの設計。もう少し大規模になると、サービス層と永続化層の間にLogic層を挟むことを検討する。
• View層（プレゼンテーション層）にはテンプレートエンジンを導入。JavaだとVelocityとかFreeMarker、PHPはSmartyなど。PHP自体がテンプレートエンジンだけど、そのレベルでは保守性からみてダメで、ちゃんと処理・データとテンプレートが分離されている必要がある。
• Controller層では、View層（ブラウザ）からのリクエストを受け取って、ビジネスロジックに繋ぐ。Controllerにはビジネスロジックは記述しない。１画面（や、１機能）に対して１コントローラが存在する設計（P of EAAのPage Controllerパターン）と、システム内で一つのコントローラがすべてのリクエストをハンドリングする方法(P of EAAのFront Controllerパターン)があって、別にどっちでもいい。
• Service層（ロジック層）は、Session Facadeとして定義。トランザクションを意識した設計にする。
• 永続化層は、どの言語でもすぐれたフレームワークがたくさんあるので導入する。種類が色々あるので特性を理解して選定する。というか、実は選定はどれでもよくて、メンバーに特性を理解させることが重要。
• DaoとEntityにMockオブジェクトを定義するのは、Service層の自動テストを書くときにMockオブジェクトを利用したテストを実行するため。あとは、ビルドパラメータでmock/releaseの切り替えできるようにしておくことで、データベースに接続できない環境で画面を動かすことができる。
• また、某所では、サービス層のMockオブジェクトも定義するルールになっていて、プレゼンテーション層とロジック部分の開発の切り離しをしていた。これも上手くまわっていた。
• 上図にでてきていない部分としては、例外設計とログ設計重要。ちゃんとやる。あと、パターンの理解重要。同じ用語と概念でシステムについての会話ができるようになる。

そんなこんなで、なんでこんなことするかというと、すべては「テストを書きやすくするため」です。
TDDまでいかなくても、テストまで書くサイクルがきちんと回っているプロジェクトの場合、そうでないプロジェクトと比較すると品質がとてもよいです。経験上。

で、テストをちゃんと書くするために、層を分離しましょうということになります。その結果、コンポーネントの独立性がたかくなって、保守もやりやすくなる。まさに、いいことずくめ。

自動テスト実行、自動ビルド、構成管理、カバレッジ、メトリクス、コード規約、コードの自動精査など、他にもまだまだおもしろそうな話題がいろいろありますよ。

というわけで、つづく。
やっぱりコード書けばよかった。

かねこ（ ´_ゝ｀）