所(@ctokoro_me)です。
弊社のメインサービスであるクラウドワークスのフレームワークをRails3からRails4へと移行を行った事に関しての連載です。本記事ではアップグレードに際してのテスト戦略とリリース戦略に関して書きたいと思います。
サービスを開始して4年を超えたクラウドワークスのコードベースは、今回行われたフレームワークのバージョンアップのような大規模な変更は未経験でしたが、開発体制として自動テストと継続的インテグレーション(CI) は早い段階から組み込まれており、今回のRails4移行においてもCI上で Rails3/Rails4 のクロスビルドは行われておりました。
しかし、特に直近のクラウドワークスは事業規模もエンジニア数も急拡大した時期であり、それに伴いコード量も10万行を超えコードの成長速度も加速していったものの、自動テストの拡充はコードの成長に追いついているとは言えない状況でした。
クラウドワークスエンジニアの八木です。 先般の記事でも触れられていた通り、クラウドワークスではシステムのフレームワークとして採用している Ruby on Rails を 3 系から 4 系に移行しました。
残念ながら、「こことそことあそこを直して、さあリリース！！！」とはいかず、それなりの時間を投入して行いました。
今回は、Rails のバージョンアップをスムーズに行えないという技術的課題は一旦脇に置いておいて、フレームワークのバージョンアップという「事業の KPI に直接寄与できない開発課題」に対して、クラウドワークスの開発チームがどのように取り組んだか、組織体制の話を書いてみたいと思います。
まず、クラウドワークスで Rails4 対応するために組んだ組織構成について、時系列に沿って簡単にご紹介します。簡単にご紹介と言いつつ先に要約すると、最初は Rails4 対応に専任チームを設けていて、最終的にはテストを全エンジニアで分担して時期を調整しながらリリースを進めました、といったところです。
当時インフラを担当していたエンジニア1〜2名で、検索負荷の対策や開発環境の構築、いろんなインフラタスクの合間に Rails4 の対応を始めました。この間は、アップグレードガイドを参照して修正を行ったり、Rails4 に対応させるパッチを書いたり、テストの拡充をしていたりしました。
だんだんとエンジニアが増えていくにつれてプロジェクトも増えていき、サーバ構築の自動化と Rails4 対応が並行して行われている時期がありました。しかしそれでは中途半端ということで、一旦インフラのメンバーはサーバ構築の自動化に注力し、Rails4 対応は小休止する期間がありました。
インフラ自動化がひと段落したあと、 Rails4 対応する組織が、正式に「Rails4チーム」として発足しました（筆者もこのときからジョイン）。
まずは Rails4 で CI を動かしたりアプリケーションを立ち上げてひたすらバグ潰しを行い、ある程度目処が立ったところでテスト環境の構築*1や、機能ごとに Rails4 をリリースすることができる環境を作るためのインフラ構成変更を担当しました。
テスト環境の準備が整ったあと、クラウドワークス全体の機能を分割して全エンジニアに割り振りました。それぞれの機能はリリースする日がスケージューリングされていて*2、割り振られた各エンジニアがスケジュールから逆算したテスト期間でテストを行っていました。
Rails4チームはプロジェクト全体進行役として、テスト環境の更新やリリース、特急で作った新インフラ構成の運用を自動化する作業などを行っていました。
晴れて全機能を Rails4 化させたあと、Rails3/Rails4 を互換で動かすためのアプリケーションコードや、並行運用に使ったインフラリソースのコードを消すために、お掃除週間を設けました。全リリース終了後に、Rails4 チームだったメンバーが一週間集中して、残課題の解消に取り組みました。
続きを読む前回のブログに引き続き、Rails3からRails4にアップグレードした際に行った工夫をご紹介したいと思います。前回の記事を未読の方は、合わせてどうぞ。
今回は、「モンキーパッチ」に焦点をあてて、取り組みを紹介します。安全な並行稼動を実現するために、いくつかのモンキーパッチを作成しました。作成したモンキーパッチを振り返ってみると、以下のように分類することができます。
今回の記事では、それぞれどのようなモンキーパッチを当てながらリリースを進めていったかをご紹介します。
続きを読むクラウドワークスのエンジニアの森田（@minamijoyo）です。
ついにRails5がリリースされましたね。今日はRails5じゃないですけど、Rails3/4並行稼働させた話をしようと思います。Railsバージョンアップを検討している方々の参考になれば幸いです。
去る2016/03/28 「Rails Upgrade Casual Talks」というイベントでRails3/4並行稼働させる仕組みを作ってる話をしました。 イベントの模様はエンジニアブログにきびたん(@ctokoro_me)がまとめてくれてるのでこちらを参照して下さい。
上記のイベントで発表した内容はこちらです↓
その後、並行稼働させつつ業務機能ごとに段階的にアップグレードを行い、無事にすべての切り替えが終わったので、 Rails3/4並行稼働の仕組みのおさらいと、実際にやってみて良かったこと悪かったことなどを共有します。
イベントでは時間の都合で、URL振り分けをするnginxのリバプロ層のところの説明をだいぶ端折ったので、この記事ではそのあたりの補足説明を多めにしようかと思います。
続きを読む大場です。
先週はRails5リリースされたように大きな動きのあったRails界隈ですがいかがお過ごしでしょうか。
2016年3月に弊社セミナールームで開催したRails Upgrade Casual Talksの中でも話題にしていたようにCrowdWorksでは、Rails3からRails4へのアップグレードに取り組んでいました。
Rails5がでたところ今さら感も漂いつつあるかもしれませんが、さる2016年6月13日からCrowdWorksはサービス全体がRails 4.2.6で稼働していますことをここにご報告いたします🎉 *2
根幹となるフレームワークを古いまま使い続けることは、洗練された記法が使えなかったり、高速化最適化が進んだモジュールが使えなかったり*3、周辺gemの対応についていけずに置いていかれるリスクなどが負債となって積み上がっていきます。また、セキュリティの問題が修正されなくなるリスクもあるため長い目でみてユーザーに不利益になり、生きたサービスを開発し続けるためにはフレームワークのアップグレードが不可欠と感じています。
稼働中のサービスのRailsをアップグレードするということは、単に bundle update するだけでは終わりません。ましてやCrowdWorksのような10万行を超えるサービスの中心となるフレームワークを更新していくことにはいくつもの課題があります。社内では「車を走らせながらエンジンを取り替えるようなもの」と課題の大きさを比喩しています。
稼働したサービスを止めずにRailsのアップグレードをするにあたって、段階的な移行を実現するためにRails3とRails4が共存できる環境を構築しました。これによってサービスの特定の機能だけRails4にして公開することが可能になります。問題の発生箇所を絞り込んだり、即座に切り戻しできたり、いちどにたくさんの(制御しきれないほどの)問題が起こることを避けることができました。
このような取り組みのお陰で大きな障害を出すこともなくユーザーへの影響も最小で移行しています。その他、実際にどういう課題に取り組んでどう解決していったかというお話は次回以降に取り上げていきます。
Railsアップグレードを行って得た知見を開発メンバーが各々の視点からブログを書いてゆくシリーズをはじめます。今週から来週にかけてRails4アップグレード記事を公開していきますのでおつきあいくだされば幸いです。
これらはきっとRails5へのアップグレードへの対策としても役に立つことでしょう。CrowdWorksエンジニアブログの更新をお楽しみに！ 🏃💨💨💨
*1:OGP画像: https://www.flickr.com/photos/blue_quartz/2413163162
*2:Rails5リリースよりはぎりぎり先に移行できたということでご容赦を...
*3:遅くなることもママありますが
© 2016 CrowdWorks, Inc., All rights reserved.
