2017-01-20

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

Serverside

サーバサイドエンジニアの中村です。今回はトレタの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アップグレードの手順

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

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

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

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

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

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

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

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

QAテスト

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

本番環境にデプロイ

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

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

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

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

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

まとめ

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

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

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

2016-12-19

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

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

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

要望レビュー会

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

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

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

店舗ヒアリング

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

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

f:id:NiPeke:20161219001222j:plain

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

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

さいごに

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

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