新旧サービスのデータを同期する仕組みを導入
モノリシックからマイクロサービスへと移行するのに伴い、データのマイグレーション（移行）も発生する。新サービスで旧サービス時代のデータを使わなくていいのならいいが、今回の移行対象が資料管理システムなのでそうはいかない。先述したように、旧サービスと新サービスとの間にデータ同期バッチを配置し、旧サービスにあるデータを新サービスに同期するようにした。
今回はXPのプラクティスとしてTDDを導入していることもあり、このデータの同期バッチもTDDの対象とした。実際のテスト（検証）はGaugeで自動テストを行い、さらに手動テストも行い正確性を担保した。
Gaugeの自動テストではデータがストレージ（Amazon S3）やデータベースに入っているか、資料の状態などの確認、移行失敗時のロールバックの確認、手動テストではデータ移行前後で資料に表示崩れがないかの確認、移行バッチ実行時の負荷テスト、各種設定の確認などを行った。
こうしてデータを同期できる状態にできたことでChavdar氏は「モバイルアプリのリリースと施設側（PC側）のリリースを別々にできたのがうれしかったです。またシステムをメンテナンスモードにする必要がなく、ユーザーにもメリットがあったかと思います」と話す。
施設向けサービスのリリースはフィーチャーフラグを使い、新サービスが見えるユーザーを限定することでデプロイとリリースを分けることにした。データベースに新機能が表示か非表示かのフラグを持たせ、後は（Webサイトの）テンプレート側でどう見せるかを切り替えている。
保護者向けモバイルアプリもフィーチャーフラグを用いた。モバイルアプリで新しいものをリリースしようとするとストアに申請するなど手間がかかるが、フィーチャーフラグを使えば表示を切り替えることになるので不具合が発生してもロールバックしやすくて開発者としては安心材料になるのではないだろうか。またモバイルアプリでもエラーが発生したら旧画面に遷移するようにフェイルセーフの仕組みをいれておいた。
最後にモノリシックからマイクロサービスへと移行することで、Chavdar氏は「資料室に限っては冒頭で挙げたようなさまざまな蓄積された問題が、かなり解消されていると感じています」と話す。
例えばシステム改修の影響は対象システム内に閉じていること、デグレが起きても他の全てが戻ることはなくなり、リリース調整のためのチーム間コミュニケーションは不要で独立してデプロイできるなど。マイクロサービスのメリットを享受できている。
岡村氏はXPを実践した感想と学びについて次のようにまとめた。
「XPのプラクティスを導入したことで安全に素早くリリースできる状態になりました。プラクティスはどれも効果を発揮したが、中でも特にペアプロが大きかったかなと思っていて、属人化がなくなり、知識がチームの中で流れ続け、メンバーそれぞれが得意分野を発揮しつつ他の分野でも成長できたと思います。あと自動テストを初期から入れたことで安全に開発を進めることができました。期限が迫ってくると『テスト書かないほうが早くすむのでは』と誘惑に駆られたりするが、そもそも何を実現したくてテストを書いているのか、一瞬だけ早さを出して本当に嬉しいのか等、本来の目的に立ち戻ることが大切です。また既存サービスとの関わりは難しいので、仕様や制約の調査をすることも大切です。
そして仕様の変更やXPの導入などは初めての取り組みでしたので、プロジェクト完了まで8カ月間を要しました。一番大変だったのは最初のチームがリズムに乗るまでの初動でした。この経験をもとに他のチームではこの難関をより早く乗り越えていきたいと思っています。今後はより複雑で他のサービスとの依存度が高いものでマイクロサービスへの移行に挑戦していきたいです」
