トレタのRailsを4.2にアップグレードしました

サーバサイドエンジニアの中村です。 今回はトレタのAPIに使っているRailsのバージョンを4.1.12から4.2.7.1にアップグレードしたので、その手順について紹介いたします。

トレタのAPIでrake statsを実行した結果は以下の通りです。同じ規模感のサービスのRailsをアップグレードするときに役立てていただけたら幸いです。

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          | 19554 | 16806 |     165 |     831 |   5 |    18 |
| Helpers              |   267 |   244 |       0 |      24 |   0 |     8 |
| Models               | 10685 |  6564 |     161 |     435 |   2 |    13 |
| Mailers              |   345 |   295 |      10 |      17 |   1 |    15 |
| Javascripts          | 14813 | 10032 |      16 |    1270 |  79 |     5 |
| Libraries            |  1316 |   992 |      24 |      89 |   3 |     9 |
| Concern specs        |   478 |   396 |       0 |       3 |   0 |   130 |
| Controller specs     | 23935 | 21178 |       1 |       3 |   3 |  7057 |
| Helper specs         |   147 |   118 |       0 |       0 |   0 |     0 |
| Lib specs            |   416 |   375 |       0 |       0 |   0 |     0 |
| Mailer specs         |  1958 |  1678 |       0 |       1 |   0 |  1676 |
| Model specs          | 11251 |  8762 |       0 |       2 |   0 |  4379 |
| Request specs        |    91 |    66 |       0 |       0 |   0 |     0 |
| View specs           |   679 |   574 |       0 |       0 |   0 |     0 |
| Worker specs         |  2906 |  2530 |       1 |       3 |   3 |   841 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                | 88841 | 70610 |     378 |    2678 |   7 |    24 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 34933     Test LOC: 35677     Code to Test Ratio: 1:1.0

サーバサイドチームのルールとして、APIの機能開発を行うときは必ずRSpecでのテストを書くようにしているので、テストが存在しないclassはほぼありません。現在、テストケースの数は約3000ケースあります。

Railsアップグレードの手順

手順は以下のように行いました。

  1. railsのバージョンをアップグレードする
  2. その他に依存するgemをbundle updateでアップグレードする
  3. rake rails:updateを実行する
  4. テストを全て通す
  5. staging環境にデプロイし、QAテストを行う
  6. 本番環境にデプロイ

非互換な変更や修正するべき部分の確認はRailsアップグレードガイドを参考にしました。

gemをbundle updateでアップグレードする

rails本体のバージョンをアップグレード後、テストを実行します。 この時点で1/3ぐらいのテストが落ちていたので、落ちたテストのstacktraceを確認して、関連しそうなgemをbundle updateで1つ1つアップグレードします。

ここで陥った問題として、csso-railsのバージョンを上げすぎてしまい、therubyracerで読み込めないJavaScript Codeが吐かれてしまいrake assets:precompileが失敗してしまいました。

この問題はcsso-railsのバージョンをダウングレードして回避するという方法を取りました。他の方法としては、therubyracermini_racerやNode.jsに置き換えると方法が考えられます。

関連するgemを全てアップグレードし終えたら、落ちるテストが10件ほどになったので、残りは1つ1つ地道に修正しました。この時点で、全てのテストが通りました。

QAテスト

staging環境にRailsアップグレード用ブランチをデプロイし、QAテストを行います。 テスト期間を2週間設けて、QAエンジニアとアプリ開発チームの協力の元、念入りにQAテストを行いました。

本番環境にデプロイ

通常のAPIのデプロイは週1回、平日昼間に行っていますが、今回のアップグレードはトレタを利用していただいている店舗さまへの影響を最小限にするために、深夜にデプロイを行いました。

EC2インスタンスの数を通常の倍に増やし、半数はアップグレードブランチのデプロイがされないようにしておき、万が一のためにすぐ切り戻せるようにしておきます。

デプロイ時、一部のテストが実行時間依存になっていることが原因でテストが落ちたことや、EC2インスタンスのネットワークが不調でデプロイ失敗など波乱がありましたが、無事デプロイ完了しました。

半日ほど様子を見て、本番で問題が起きていないことを確認後、古いコードが乗っているEC2インスタンスを削除し、全てのサーバーが4.2系のコードに切り替わりアップグレード作業が完了しました。

特にお客様からのお問い合わせも無く、安心してお店でトレタを使っていただいています。

まとめ

トレタのAPIのRailsのバージョンを1年半ぶりにアップグレードしました。 トレタのエンジニアはまだ人数も少ないこともありますが、基本的に機能開発をメインとするエンジニアしかおらず、リファクタリングや開発基盤構築をメインの職責とするエンジニアはいません。

しかし、継続的にコードを改善していく文化が根付いており、日頃から小さい改善を積み重ねていくことで、コードが大きな負債にならないように日々努力しています。今回のアップグレード作業でもほぼ問題なく、スムーズにアップグレードすることができました。

トレタでは機能開発が大好きで、継続的なコードの改善をやりたいというサーバサイドエンジニアを募集しています。トレタに興味を持たれた方はぜひこちらからご応募お願いします!

最速かつ継続的に価値を届け続けるためのユーザー理解

こんにちは。デザイナーの上ノ郷谷です。私たちトレタが提供している予約/顧客管理サービスは、ユーザーである飲食店のスタッフからみると会社が選んだ業務ツールです。しかも予約や顧客を管理することは飲食店にとって大切とはいえ、メインの業務ではありません。そういった現場で使ってもらい、サービスの価値を上げていくには、いつも通りに使っていたら、気付かないうちに便利になっていると感じてもらえるような、できるだけ早く、継続的に価値を提供していく必要があると考えています。使うための学習や、操作中の迷い、没入させてしまったりすることがすべてコストになってしまうからです。

そのために私たちは、根源的なユーザー理解と、開発チーム内での認識にブレがないように情報フォーマットを持って、コミュニケーションコストを下げるなど、さまざまな取り組みを行なっています。今回はその中でも根源的なユーザー理解のために行なっているいくつかの取り組みについて書いてみます。

要望レビュー会

トレタではセールスチームやサポートチームがユーザーから聞いた要望を投稿するフォームが用意されています。ここで投稿された内容はスプレッドシートに蓄積されるだけでなく、社内コミュニケーションツールとして使っている Slack の専用チャンネルにも流れます。この要望をデザイナーとセールスチームのメンバーとで毎週レビューする会を行っています。

この会ではどういった店舗からの声なのかだけではなく、手段の提案に近い要望の背景にある課題や、プロダクト上で何が問題になっているかの現状把握、運用面での工夫を含む、解決プランの提案、検討中の仕様共有も行います。デザイナーはこのヒアリング会の中で手段の提案になりがちな要望から課題を抽出することを意識しています。

要望レビュー会は、ユーザーの理解以外にも、セールスチームのメンバーと製品開発メンバーの距離を縮めて保つことも目的のひとつです。

店舗ヒアリング

要望レビュー会のなかで、その要望がどんな店舗からあがっているのか、店舗の立地や規模など課題を明確にするために知るべき事があったり、直接話を聞いてみたいと思った場合はすぐに担当のセールスメンバーに声をかけて、訪問させていただくようにしています。店舗でのヒアリングはデザイナーだけではなくエンジニアも行くことがあります。

店舗でのヒアリングは、基本的に営業時間中ではなく、開店前の準備中だったりします。貴重な時間のなかで、しっかり話も伺いたいので聞きたい内容は事前に準備します。ですが、実際は雑談形式になる事が多いです。事前に用意した「聞くこと」についてももちろん尋ねますが、できるだけ業務中に近い内容を話してもらうためだったり、雑談の方が普段抱えている課題を引き出しやすいのと、ある点に集中して質問して答えを求めないほうが、状況や関連している原因に気付くことが多いからです。そのため私は、ヒアリング時はノートではなくカードに、話を聞いていて気になったキーワードを書くようにしています (私は付箋だと書くときにあつかいにくいので、メッセージカードを使っています)。

f:id:NiPeke:20161219001222j:plain

会社に戻ったらキーワードを書いたカードを机の上に、事前にまとめていた聞きたかったことを基準にマッピングしていきます。そうすると雑談で前後したりしていた話の筋がすうっと通り、業務時間外のインタビューでは知ることが難しかった現場の声が見えてきます。このマッピングしたカードと、要点や所感をまとめたものをすぐに社内情報共有ツールを通して、メンバーに共有しています。

導入店さまには営業中にも客としてもお邪魔します。基本的に食事を楽しむためですが、どういったタイミングで何をするためにどれくらいの時間 iPad に触れているかを見たりしています。余談ですが、会社からも導入店さまの店に行くことを推奨されていて、それを補助する福利厚生もあります。

さいごに

ほかにも根源的なユーザー理解のための取り組みはありますが、特徴的なものを挙げてみました。私たちはサービスの価値を上げるために、サービス提供者という立場にいながらも、できるだけユーザーと同じ視点でサービスに触れる必要があります。その視点から課題を明確にし、仮説検証、改善プランのレビューを重ね、提供する価値の精度を高めるというイテレーションを回し続けることで、最速かつ継続的に価値を届け続けるプロセス、組織を作っていっています。


この記事はトレタ Advent Calendar 2016の記事です。はインフラエンジニア津田の「明日からできる日常の自動化」でした。は QA エンジニア井上の「Todoist で始めるタスク管理」です。

DevFest.Asia 2016 Singapore にいってきました(前編)

f:id:ryotah:20161215231207j:plain

この記事はトレタ トレタ Advent Calendar 2016 15日目の記事になります。

こんにちは、フロントエンドエンジニアの堀口です。
弊社のカンファレンス補助制度を利用して、DevFest.Asia 2016 Singapore に参加してきました。

DevFest.Asia は CSSConf.Asia 2016 SingaporeJSConf.Asia 2016 Singapore 、2つのカンファレンスをあわせたものです。

開催日は11月24日〜26日の3日間。ちょうど、トレタ(Web版) のシンガポール対応の時期と重なっていたため、現地のスタッフへのプレゼンも兼ねてシンガポールへいってきました。

今回は、前編で面白かったセッションを、後編でカンファレンスの雰囲気を、簡単に紹介したいと思います。

セッション紹介

カンファレンスのスライド一覧は以下から確認できます。
devfestasia/talks: List of talks with slides (CSSConf.Asia and JSConf.Asia)

資料が公開されていて、個人的に興味深かったセッションを紹介します。

CSSConf

Make websites, not apps

... At least, web developers don't have to build the browser first. And we get so much built-in in browsers already

Mozilla の人による、「ブラウザにはいろいろ便利な機能があるんだよ。まずはそれらを使ってみましょう」というお話。

他のセッションも結構そうだったけど、CSSの日なのにCSSの話じゃなかったりと、結構自由です。

The Evolution of CSS4 Color

W3C のテクニカルディレクターによる「色」の話。CSS4の話はちょっとだけです。

CSS (Variable) Secrets

CSS Variables are a revolution for separation of style and behavior

CSSの変数の話。CSS Variables & JavaScript とか見ると胸があつくなります。

JSConf

Performance Profiling for V8

Google の人によるChrome V8の最適化の話。

From Zero To Binary Search Tree

(スライドと動画がなかったので、別のカンファレンスから)

データ構造の話。List, HashTable, Stack, Queue, Graph, LinkedList, Tree, BinarySearchTree についての説明と実装方法について。

コードは GitHub で公開されてました。
itsy-bitsy-data-structures/itsy-bitsy-data-structures.js at master · thejameskyle/itsy-bitsy-data-structures

Applying The Magic Of Neural Networks

ニューラルネットワーク、機械学習の話。RPGっぽい話(攻撃、防御、回復どれにする)から説明に入るので、わかりやすい印象があります。

NeuroJS: Capturing And Visualizing Brainwaves With Angular 2

デモが途中で失敗したり、解決方法を Stack Overflow で調べたり、一番もりあがったセッションはこれかもしれないです。内容も面白いです。ちなみに、Angular はあんまり関係ないです。

Wombat-Driven Understanding: An Interactive Guide To Using npm

npm 入門の話。プロジェクトを作って公開するまでを説明してくれます。
Show Notes for live coding in WDU talk at jsconf.asia, 26 Nov 2016 も一緒に見るといいと思います。

Yosuke Furukawa - Exploring Future Node

Node.js の今までとこれからの話。v8.x, HTTP/2, ES Module の話など、未来の話を聞くのは楽しいですね。

まとめ

テーマが幅広いこのようなイベントだと、普段気にしていない情報のキャッチアップや、気になっているけど放置してしまっている技術の勉強ができてとても楽しいです。
直接仕事には使えないけど何か楽しいぞ、という話に触れられるのもいいですね。

カンファレンスの雰囲気がどのようなものだったか、は後編に書きたいと思います。(たぶん来週のどこかで)


トレタ Advent Calendar 2016、明日は フロントエンドエンジニアのすえださんに FluxとDDDについて考えてみた を書いてもらいます。お楽しみに!

© Toreta, Inc.

Powered by Hatena Blog