ラクスルに入社してから今月でちょうど入社から1年経った新米エンジニアの泉です。
思い起こすと「一年色々あったなぁ」と感傷にふける今日この頃です。
さて、9月上旬に行ったAWS移行について、インフラチームの渡邉よりインフラ側のブログ記事がありましたが、今回はアプリ側がどのような準備を経て移行をしたかを説明します。
全体の流れ
AWS移行に向けたアプリ側の対応は、
- 7月
- 各部署ヒアリング
- テストシナリオ作成
- QA環境構築
- 8月
- テスト・修正
- カスタマーサポートによるテスト実施
- ビジネスユーザーによる受入テスト実施
- 9月
- コードフリーズ
- 最終受入テスト
- 移行作業・移行後テスト
- 本番で上がってくる課題を潰しまくる
といった流れです。改めて見ると「え?やったことってほとんどテスト?」と言われそうですが、実際その通りだと思います。集中して進めていた二ヶ月間は、ほぼ全てテストに始まり、テストに追われ、テストに終わる、という感じでした。
前回の「インフラ編」のブログにもありましたが、移行後に「問題があった箇所」というのは、一部を除けばほとんど「QAでテストしきれなかった部分」になります。
逆に「QAでテストできた部分は本番でもほとんど問題が起きなかった」とも言えます。如何にQA環境で網羅的なテストケースをつくり動かせる状態にするか、というのが工夫するポイントになってきます。
テストケース作り
以下の図は、本邦初公開、ラクスルのシステムの論理構成図になりますが、様々な関係者が使うためとてもスコープが広く、テストケースも自然と膨大になります。
アクター、つまりユーザーの種類は細かい役割の違いも含めると20種以上あり、QAのテストユーザーを準備するだけでもかなり時間がかかります。
テストケースを作る際は、コマンド一発でエンドポイントを全部洗い出して…なんてそんなシステマチックな事が出来れば良いのですが、PurePHPとCodeIgniterとSymfonyが並行するウチのシステムでは、まだそんなかっこいいことは出来ません。
それぞれの種類のユーザーにヒアリングを重ねて、普段、業務管理ツールでどんな事をしているか、どのような流れで行っているか、ログイン方法は?等、細かく聞き出します。
原始的ではありますが、確実かつ効果的な方法です。上の図にでてくる人のアイコンが1チームだとすると、1チームあたり1時間位ヒアリングを行い、作業の流れを書き出していきます。で実際その作業を自分でも実際動かしてみる、ということを繰り返して、受入条件だったりを整理していきます。
記述方法は、プロダクトバックログでもお馴染みのユーザーストーリーと同じ書き方で「誰々が、何々できる」という形で統一しています。また受入条件に「こういう状態になっていたら合格」という条件も書いておきます。このフォーマットでユーザーストーリーをどんどん追加していきます。
因みに、論理構成図では書き出しきれていないものは多数あり、例でいうと「見積り業務」というのがあり、ラクスルのECサイトで販売していないような特殊な印刷物や、大部数チラシ等時間がかかってもコストを下げたい注文を取り扱うための若干複雑なワークフローも存在したりします。
このテストケースもどんどんチューニングされていきます。初め洗い出しを行ったときは300項目くらいでしたが、リリース前までに406項目まで増えました。
QA環境の構築
当初計画には無かったのですが、検証をスムーズに進めるために、QA環境という実行環境を準備しました。
はじめは、raksul.comの向き先をhostsを書き換えて新本番環境を検証環境として検証を進めようと考えていたのですが、①ビジネスユーザーにhostsを書きかえる事が負担、②今後もブラウザーテストや、独立した環境で実行できるようにしたい、という希望もあり、開発環境でも本番環境でもない、品質管理で使うための実行環境を準備しました。
その他にも今までのGlobalアクセスできる代わりにBasic認証を挟んでいた仕組みを、社内アクセスに限定してBasic認証不要にしたり、とにかく検証をするのに邪魔になりそうなものを排除しています。
PHPのlogやエラー出力の振る舞いなどはPRODと同じにしつつ、外部連携をするポイントなどは、開発環境と同じものにするという設計にして、アプリケーションがQA環境で動くための準備をします。
この時「QA環境を作ろう」と言い始めてから設計をホワイトボーディングして、インフラにお願いして、週明けにはもう環境が準備出来ていたときは、かなりテンション上がりました。
バッチもテストケース化する
当たり前ですが、バッチもテストの対象になります。バッチが何をしてくれるかは、コードをひたすら読みまくって言葉にしていきます。
例えば、デザインの見積もりと制作を行ってくれる「ラクスルデザイン」の業務ですが、ここでは案件の進み具合によってバッチが「デザイン案件がXX件未返信ですよ!」といった具合に、リマインダーメールを送ってくれたり、完了した案件で不要になったファイルを定期的にハウスキーピングしてくれるバッチなどがあるのですが、
- 「バッチは、案件毎の各種リマインダーメールを送信してくれる」
- 「バッチは、アップロードされた添付ファイルを随時バックアップして削除してくれる」
といった形のストーリーに仕立てます。
バッチが本番環境でしか実行出来ない!
悲しきかな…今までラクスルではバッチが本番以外では動いていませんでした。つまりバッチはぶっつけ本番。こういう事も整備できるのは今だけ!この機会にQA環境でもちゃんとバッチが動くように改修しました。
バッチのコードを読み、QA環境のDBだけに影響を与えるものだけであれば、そのまま走らせても問題はありません。ものによっては外部APIにデータを送ったりするものもあるので、テスト環境用のAPIが無い場合は、QA環境で実行する場合はDry Run状態にできるようにしたり、ログを仕込んで動作確認ができるようにしたりしました。
重要な実行部分がコメントアウトされていたり、cronに仕込んでいないバッチなどもあったので、そのあたりは容赦なく削除しました。晴れて80近くあったバッチは、全てQA環境で起動できるようにしました。
カスタマーリレーション部のオペレーターによるテスト実施
さて、テストケースを6〜7割実施したところで、他のメンバーにもテストを実施してもらいます。8月はお盆休みなどもあり、印刷業界は少し落ち着くので、この間にオペレーターの方に協力をお願いして、400項目あるテストをどんどん進めて頂きます。課題があった箇所は、課題シートトラッキングシートを用意して、インフラとアプリと手分けをしてどんどん問題を潰していきます。
このときに使った課題シートは、こんな感じです。
課題リスト(サンプル)[/caption]
こんな調子で、前述のユーザーストーリーの番号と紐付けて、どの部分で問題が起きたかを起票し、エンジニアが一つずつ、潰しこんで行くというプロセスを進めます。リリースまでに、この粒度感の課題をインフラエンジニアと手分けして98項目ほど潰しました。
また、テストをいざやろうとすると「URLがわからない」「ログインアカウントが無い」「このテストはできない」等、テストを進めるブロッカーが出てくるので、しばし検証を進めるためのサポートというのも、このタイミングで必要になります。
ビジネスユーザーにテストしてもらう
オペレーターによるテストが一巡落ち着いたところで、今度は実際オペレーションを行うメンバーを、各チームから1名ずつ選出してもらい、10名程にテストをお願いしました。その際準備したものとしては、
- (よりブラッシュアップされた)テストケース一覧
- QAのテストアカウントID/PW、各種ログインURL
- 決済で必要になるテストクレカ番号
- 特にトリッキーなテストはより細かいテスト手順
- 外部プロセスに依存する場合、外部のシステムをどう使えば良いかの手順書
等、オペレーターにお願いしたときよりもスムーズに他のメンバーにもテストする段取りができました。
このあたりから、テストも3巡目を迎えるので、問題も収束してきて、オペレータによるテストをやったときよりも半分以下の課題数で終わった気がします。また、このステップを通じて、ビジネスユーザーにオーナーシップを渡しています。解りやすく言えば「移行後、この機能がもし動かなかったら、それはあなたの責任です!」という自覚をもってもらう、という意図もあります。
因みに、ビジネスユーザーの一部テストに参加することで
- 初めてプロセスの全貌を理解した
- オペレーションの理解が深まった
- テストの大変さをしった
といったフィードバックがあり、いい感じにみんなの視野が広がって嬉しかったです。
また、実際人手を増やすことで更に細かいところまで見ることが出来たのもありました。コードフリーズを行った後にもう一巡テストを行ってもらい「確実に動くもの」としてファイナル版をつくります。
一番最後のテストはリリース2日前の夜23:00頃に終わったのですが、コードフリーズ後に慌てていれた変更の一つが、バックファイヤーを起こし、なんと購入導線に影響が!いやぁ、最終受入やっておいてよかった…!結局その変更は Revert して移行後に見送りしました。
次回予告
次回は、いよいよ移行準備!どのような体制で挑んだか、どんなところで躓いたか、ミートアップでは語りきれなかった詳細を披露致します!