読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

全社的にES2015のコーディングルールを導入するための工夫

標準化

英語沼から抜け出せる気がしない id:necojackarc です。

現在ピクスタでは、

  • CoffeeScript の開発自体が停滞している
  • CoffeeScript の主要機能は既に ES2015 で採用されている
  • ES2015 or later で導入されていく新しい仕様を活用したい

などを理由とし、CoffeeScript から JavaScript (ES2015 or later) への移行を進めています。

しかし、これまで ES2015 を利用してこなかったので、ES2015 に関するコーディングルールがありませんでした。

それに伴い、ES2015 におけるコーディングルールの策定と適用を行いました。

そこで、今回は ES2015 のコーディングルールを全社的に導入する際に工夫したことについて紹介します。

なんだか似たようなタイトルの記事を3ヶ月くらい前にも書いていますので、気になる方はそちらもご覧ください。

テーマについては前回とほぼ同じく、

  • どのようにしてコーディングルールを順守してもらうか
  • どのようにしてコーディングルールを一斉に適用 / 更新するか

です。

特に複数リポジトリへの設定の一斉適用に関する取り組みについて説明します。

コーディングルールの策定

ピクスタでは Ruby においては、Ruby Style Guide をベースとしたルールを適用しています。

ES2015 においては、

をベースルールとし、必要に応じて変更や追加を行っていくことにしました。

ESLint の導入

コーディングルールを遵守してもらうには、以下の記事でも言及しているように、チェックの自動化が望ましいです。

texta.pixta.jp

先ほど挙げたベースルールは ESLint で簡単に設定可能という理由もあり、ESLint を導入することにしました。

ESLint を利用することで、コーディングルールに準拠しているかを自動でチェックできます。

全社的に導入するための工夫

ピクスタではリポジトリが各サービスごとに分離しており、各リポジトリで設定ファイルを個別に管理するのは煩雑です。

ESLint には、設定をライブラリとして切り出せる機能 (Extensible Shared Config) があります。今回はこれを利用し、ES2015 のコーディングルールを中央管理する npm ライブラリを作成しました。

github.com

こちらのライブラリを利用するには、以下のような ESLint の設定ファイル (.eslintrc) を配置する必要があります。

{
  "env": {
    "browser": true
  },
  "extends": [
    "pixta"
  ],
  "globals": {
    "gon": true,
    "I18n": true
  }
}

ルールの追加や変更を行いたい場合、各リポジトリの .eslintrc は特に変更する必要はありません。eslint-config-pixta の更新のみで済むようになります。

まとめ

ピクスタでは ES2015 のコーディングルールのベースとして、

を採用しました。

コーディングルールに準拠しているかのチェックについては ESLint を導入し、複数リポジトリへの設定の一斉適用に関しては Extensible Shared Config を利用しました。

これにより、

  • コーディングルールに準拠しているかどうかのチェックの自動化
  • Extensible Shared Config による全リポジトリへの一斉適用

が達成できました。

エンジニア総出でE2Eテストを拡充した話

Rails テスト

はじめまして、開発部で技術基盤を担当しているid:Yasaichiです。 乃木坂46の橋本奈々未さんを推しすぎて、デスクに雑誌の切り抜きを飾っています。 本エントリでは、先日行った技術改善の取り組みについて紹介したいと思います。

はじめに

PIXTAは、「本体」と呼ばれるモノリシックなRailsアプリケーションと、そこから切りだされた複数のマイクロサービスで構成されています。 現在、これらの中で、Rails 5のリリースによって完全にサポートが切れる4.1系(とそれ以下)で動作しているアプリケーションのバージョンアップを計画しています。

This means 4.1.x and below will essentially be unsupported!

Riding Rails: Rails 5.0.0.beta1: Action Cable, API mode, Rails command

ピクスタではこれまで、サービスの広範囲に影響するような大規模リリース*1を何度か行ってきました。 このようなリリースの際には手作業でテストシナリオを確認していたのですが、今後Railsのバージョンアップを継続的かつ安全に行うために、このタイミングでE2Eテストを拡充することにしました。

そこで、ゴールデンウィーク明けの2週間を使って、E2Eテストをただひたすら書くだけのカピバラ*2合宿を開催しました。 ピクスタでは、以前から「プチ改善祭り」と称して日頃後回しにしてしまった技術改善のタスクに取り組む日を不定期に設けていましたが、2週間まるまる取って行ったのは今回が初めてでした。

進め方

前述のように、以前から利用していたテストシナリオがあったため、これらを各エンジニアに割り当て、各自がE2Eテストに落としこんでいく形で進めました。

参加メンバーはアプリケーションエンジニアの (リーダーを除く)ほぼ全員で、集中して作業するために会議室を貸し切り、PCとディスプレイ、おやつ*3を持ち込んで行いました。 期間中は開発業務が滞ってしまうことになるので、あらかじめ経営陣の了承を得た上で、期間中の不具合などはリーダーが対応するようにしました。

f:id:Yasaichi:20160614182200p:plain コーディング中の様子(全員揃ったときの写真を撮れず…)

E2Eテストを書く際のルール

ピクスタでは、自動テストをRubyのテスティングフレームワークのひとつであるRSpecを使って記述しており、E2Eテストではcapybaraと組み合わせて利用しています。 今回、E2Eテストの質を担保するため、いくつかのルールを定めました。 以下でその一部を紹介します。

なお、これらのルールをただ示すだけではなく、一部のシナリオに対するE2Eテストを事前に用意し、適宜これを参照してもらうようにしました。

capybaraのbult-in DSLを使う

bult-in DSLには、featurescenarioなどがあります(詳しくはこちら)。 これらはそれぞれ、describe ... type: :featureitのエイリアスになっています。 このDSLを使って既存のテストシナリオを記述したところ、よりわかりやすく感じたので、こちらで統一することにしました。

ページの要素はできるだけI18nを使って指定する

これは、一度書いたテストコードをそのまま他の言語でも利用できるようにするためです。 現在PIXTAは日本語だけでなく、英語、中国語(簡体字繁体字)、タイ語で展開しているため、テストコードでも多言語対応を意識する必要があります。

js: trueオプションはJavaScriptが必要なシナリオのみで使う

JavaScriptを有効にするとよりユーザー環境に近いテストを行うことができますが、その分実行に時間がかかるようになります。 現在、前述した「本体」だけでも3万を超えるテスト項目が存在しており、分散テスト実行システムのRRRSpecを使って高速化しているものの、テストの実行時間には気を遣うようにしています。

Pull Requestとコードレビュー

コードレビューについては、メンバーから「E2Eテストを書くだけであれば、プロダクトコードを変更しないので必要ないのでは」という意見も出ました。 しかし、プロダクションコードと同様、テストコードも継続的にメンテナンスしていくことには変わりありません。 そこで、通常の場合と同じく第三者のレビューを受けた上でmasterブランチにマージするというフローで行いました。

なお、プロダクションコードの場合と異なり、レビューに(それほど)深い業務知識が求められないこともあり、レビュアーの決定はArray#sampleを使ったおみくじで行いました。

成果

今回の取り組みによって、サービスの重要な機能に対してE2Eテストを一通り用意することができました。 また、参加したメンバーの中にはE2Eテストを書くことに慣れていない人もいましたが、短期間で集中してテストを書くことによってスキルアップすることができました。

まとめ

本エントリでは、Railsのバージョンアップを継続的かつ安全に行うために開催したカピバラ合宿について紹介しました。

一定の期間を取り、エンジニア全員で集中して技術改善に取り組むことで、次のような成果を上げることができました。

  • サービスの重要な機能に対してE2Eテストを一通り用意することができた
  • メンバーの能力を底上げすることができた

一方で、エンジニア総出で取り組むということは、期間中は開発業務が滞ってしまうことになります。 そのため、運用フローやルール等を事前に考え、しっかりと準備をした上で実施することが(当たり前ですが)とても大事だと感じました。

ピクスタでは、サービスを継続的に開発・運用するための技術基盤を支えるエンジニアを募集しています!

*1:Rubyのバージョンアップや多言語対応など

*2:E2Eテストのフレームワークであるcapybaraにちなんでいます

*3:最終日にはなぜかRedBullの差し入れもありました