⠀人
/ ⁰⊖⁰ \ オカメインコエンジニアの五十嵐(@ganta0087)です。
本連載のなかでRails 3/4の環境を並行稼動させたことについては既にお話させていただきました。 この状態で今までどおりの監視をしていると、何か問題が発生したときにRails 4が原因なのかが切り分けづらくなってしまいます。そのため、次のようなことを追加で行うようにしました。
これによってRails 3のときとは異なる事象を発見したり、エラーの原因の調査に役立つことが期待できます。 実際にアプリケーションサーバーでRails 3のときよりも負荷の上がる事象が発生し、特定のコントローラーで問題が発生していることがすぐに特定できました。
今回はこれらの設定方法について紹介します。
所(@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のリバプロ層のところの説明をだいぶ端折ったので、この記事ではそのあたりの補足説明を多めにしようかと思います。
続きを読む© 2016 CrowdWorks, Inc., All rights reserved.
