mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

mixiページリリースまでの開発フロー紹介

過去に名前だけチラっと出た事があるのですが、記事を書くのは初めてです、masartzです。

mixiページのリリース

去る2011年8月31日、mixiに新しいサービス「mixiページ」がリリースされました。

サービスの内容については、実際の画面プロモーションページを参考にしていただいても良いですし、リリース後2日間で7万件のページ作成をしていただいた実績などから、ある程度認知していただけていると判断して割愛いたします。

今回は、サービスリリースまでの裏話などを語って行きたいと思います。

mixiページのアプリケーション開発には私が所属するチームのメンバーがほぼフルコミット状態で携わったため、主要開発メンバーは7人という状態でした。これ以外にmixiページアプリのプラットフォーム開発に別チームのメンバーが数人携わっています。

mixiの開発におけるメンバー構成は、少ない場合は1人からで、多くても5人を超えるケースは稀であり、今回はかなりの大所帯でした。

最初に何をしたか

その中で、最初に以下の内容を取り決めました
  • モジュールの名前空間と設計方針
  • テストの精度(項目)
名前空間及び設計方針については、たんぽぽTにも相談しつつ大まかなモジュール構成を整理しました。

mixiでは1つのリポジトリに全てのサービスが詰まっているため、名前空間の衝突や 命名規則なども周りに合わせる必要があります。

今回はさらにチーム内で全体像の共通認識を取る、その上で役割分担を考える、を狙いとして実施しました。

個人的にはこの時点である程度整理できた事は良かった点として挙げられると思いますが、仕様の追加・変更を考慮してもう少し柔軟にしておけば良かったかなというのが反省要因です。

テスト精度については、『どのレイヤでどこまでテストするか』という項目の整理になります。

例えば
  • DBにアクセスする部分であれば、「INSERTしたら、その行を取得してis_deeplyで要素確認する」
  • コントローラー層では「HTTPのレスポンス値が正しいことを確認する」
などを取り決めることでレイヤ間での過不足、.tファイル間での濃度を揃えられました。

テストの項目が決まる、ということは.tファイルの中身が大体決まると言えるためベーシックな部分は都度書く必要がないように簡単なスケルトンツールをあらかじめ作成しました。

mixiのテストコードの配置はリポジトリ内でルールがある(いまからでも間に合う開発者テスト)ので、そのルールに基づいて 適当な箇所に.tファイルが作られるような簡単なものです。

開発中の継続的インテグレーション

このプロジェクトは開発中からブランチ独自で継続的インテグレーションの仕組みを導入していました。
「このブランチも Buildbot で追うようにして、結果をこの IRC チャンネルに書きこんでほしい」といった要望をうける機会がふえてきました。」 (Jenkins はじめました + ほか3つ) のあたりは実はこのプロジェクトの事を指していました。

ソフトウェアがbuildbotからjenkinsになったのは本プロジェクトブランチでの稼動実績があったから(!?)なのでした。

開発中に起きることは、モジュールのIF変更から、ついうっかりなバグ混入まで様々です。

その中で進めるのに重要なのは「テストが落ちるのに慣れないこと」かなと感じました。

リリース! の前に...

開発が完了すれば、いよいよリリースです。

開発ブランチの差分をtrunkにマージしてコミット...の前に、今回についてはいくつかの段階リリース(先行リリース)を行いました。

案件が新サービスの開発だったため、既存のモジュールの修正は比較的少なく、あるとすれば機能追加が主なケースです。 そのような修正をリリースする際に、
  • trunkマージの際の予期せぬコンフリクト
  • モジュールを使っている既存サービスへの影響
があると、リリース時の余計な対応が増えるため、これを防止することを目的としていました。 これは今回のプロジェクトが大規模だったからではなく、mixiサービスという大きいリポジトリに対してコミットする弊社のアプリ開発全般において進めていった方がいい取り組みだと考えています。

今度こそリリース! が、しかし...

開発終了と先行リリースが完了したことで、とうとう本リリース!

と言いたいところですが、今回の案件では通常とは異なり、ベータ環境を設けてのフェーズ分けリリースという形をとることになりました。

この方法は、mixiで過去に行ったケースもあるものの、稀なやり方です。
もうひとつのmixiサービスを用意する必要があり、テスト環境で試験するのとは対応が大きく異なります。
ベータ環境は限られた人にしか公開されないとはいえ、規模の違い以外はmixiの本サービスと同様の環境を準備する必要があります。
そして、そこで動くサービスには当然既存サービスの安定稼動も含まれます。

ここでjenkinsのプロジェクトをrelease版と開発版に分割しました。

release版でチェックしているリポジトリはmixiのtrunkから派生したひとつの ブランチですが、案件内でのtrunk的な立ち位置にいました。

コードレビューを通過した差分のみマージされ、これがベータ環境にデプロイされていました。

それとは別に、releaseブランチから派生した開発ブランチで 以降のフェーズの開発を続け、このリポジトリに対しても 同じように定期的にテストを走らせていました。

これのおかげで、release版の安定稼動を第一としつつ開発作業をする など、リリースしながら開発をするための環境を整えることができました。

こうしたいくつかの段階を超えて、2011年8月31日にmixiページはリリースされました。

今後のテスト方針

テスト部分に関しては、最近ではブランチをテストするためのTry Server (Jenkins で任意のブランチをテストする) が設けられました。

さらにこの後、curlでアクセスする部分を1コマンドにする対応も行われました。

今後のmixiの通常開発フローにおいては、Try Serverのテストがメインになるのではと思います。

今回は、長期間に渡って大人数で開発していたため、継続的なテスト実行はもとより それがチーム共通のIRCチャンネルに通知される、というのがjenkinsに個別プロジェクトを 立てた良いポイントだったかなと考えています。

まとめ

大規模開発であったが故に、その一部のみとなりましたが、 意外にこれまで語られることの少なかったmixiの開発フローを紹介しました。

特にこの記事は、リリース後の残タスクとして

「jenkinsで稼動している本案件のrelease版と開発版のプロジェクト稼動を止めてください」

と依頼したところ

「せっかくなので、その前にエンジニアブログに書いてください」

とのお言葉をいただいた事に端を発しているため、継続的インテグレーションの活用を中心にした話となりました。

今回は比較的長期間・大規模な案件だったため、もう少し平均的な案件のリリースフローについても今後(誰かが)紹介していければいいと思います。