はじめまして、開発部で技術基盤を担当しているid:Yasaichiです。 乃木坂46の橋本奈々未さんを推しすぎて、デスクに雑誌の切り抜きを飾っています。 本エントリでは、先日行った技術改善の取り組みについて紹介したいと思います。
はじめに
PIXTAは、「本体」と呼ばれるモノリシックなRailsアプリケーションと、そこから切りだされた複数のマイクロサービスで構成されています。 現在、これらの中で、Rails 5のリリースによって完全にサポートが切れる4.1系（とそれ以下）で動作しているアプリケーションのバージョンアップを計画しています。
This means 4.1.x and below will essentially be unsupported!
Rails 5.0.0.beta1: Action Cable, API mode, Rails command | Riding Rails
ピクスタではこれまで、サービスの広範囲に影響するような大規模リリース*1を何度か行ってきました。 このようなリリースの際には手作業でテストシナリオを確認していたのですが、今後Railsのバージョンアップを継続的かつ安全に行うために、このタイミングでE2Eテストを拡充することにしました。
そこで、ゴールデンウィーク明けの2週間を使って、E2Eテストをただひたすら書くだけのカピバラ*2合宿を開催しました。 ピクスタでは、以前から「プチ改善祭り」と称して日頃後回しにしてしまった技術改善のタスクに取り組む日を不定期に設けていましたが、2週間まるまる取って行ったのは今回が初めてでした。
進め方
前述のように、以前から利用していたテストシナリオがあったため、これらを各エンジニアに割り当て、各自がE2Eテストに落としこんでいく形で進めました。
参加メンバーはアプリケーションエンジニアの （リーダーを除く）ほぼ全員で、集中して作業するために会議室を貸し切り、PCとディスプレイ、おやつ*3を持ち込んで行いました。 期間中は開発業務が滞ってしまうことになるので、あらかじめ経営陣の了承を得た上で、期間中の不具合などはリーダーが対応するようにしました。
コーディング中の様子（全員揃ったときの写真を撮れず…）
E2Eテストを書く際のルール
ピクスタでは、自動テストをRubyのテスティングフレームワークのひとつであるRSpecを使って記述しており、E2Eテストではcapybaraと組み合わせて利用しています。 今回、E2Eテストの質を担保するため、いくつかのルールを定めました。 以下でその一部を紹介します。
なお、これらのルールをただ示すだけではなく、一部のシナリオに対するE2Eテストを事前に用意し、適宜これを参照してもらうようにしました。
capybaraのbult-in DSLを使う
bult-in DSLには、feature、scenarioなどがあります（詳しくはこちら）。
これらはそれぞれ、describe ... type: :feature、itのエイリアスになっています。
このDSLを使って既存のテストシナリオを記述したところ、よりわかりやすく感じたので、こちらで統一することにしました。
ページの要素はできるだけI18nを使って指定する
これは、一度書いたテストコードをそのまま他の言語でも利用できるようにするためです。 現在PIXTAは日本語だけでなく、英語、中国語（簡体字、繁体字）、タイ語で展開しているため、テストコードでも多言語対応を意識する必要があります。
js: trueオプションはJavaScriptが必要なシナリオのみで使う
JavaScriptを有効にするとよりユーザー環境に近いテストを行うことができますが、その分実行に時間がかかるようになります。 現在、前述した「本体」だけでも3万を超えるテスト項目が存在しており、分散テスト実行システムのRRRSpecを使って高速化しているものの、テストの実行時間には気を遣うようにしています。
Pull Requestとコードレビュー
コードレビューについては、メンバーから「E2Eテストを書くだけであれば、プロダクトコードを変更しないので必要ないのでは」という意見も出ました。 しかし、プロダクションコードと同様、テストコードも継続的にメンテナンスしていくことには変わりありません。 そこで、通常の場合と同じく第三者のレビューを受けた上でmasterブランチにマージするというフローで行いました。
なお、プロダクションコードの場合と異なり、レビューに（それほど）深い業務知識が求められないこともあり、レビュアーの決定はArray#sampleを使ったおみくじで行いました。
成果
今回の取り組みによって、サービスの重要な機能に対してE2Eテストを一通り用意することができました。 また、参加したメンバーの中にはE2Eテストを書くことに慣れていない人もいましたが、短期間で集中してテストを書くことによってスキルアップすることができました。
まとめ
本エントリでは、Railsのバージョンアップを継続的かつ安全に行うために開催したカピバラ合宿について紹介しました。
一定の期間を取り、エンジニア全員で集中して技術改善に取り組むことで、次のような成果を上げることができました。
- サービスの重要な機能に対してE2Eテストを一通り用意することができた
- メンバーの能力を底上げすることができた
一方で、エンジニア総出で取り組むということは、期間中は開発業務が滞ってしまうことになります。 そのため、運用フローやルール等を事前に考え、しっかりと準備をした上で実施することが（当たり前ですが）とても大事だと感じました。
ピクスタでは、サービスを継続的に開発・運用するための技術基盤を支えるエンジニアを募集しています！
