はじめに
こんにちは！atama plusでWebエンジニアをしているProjectormatoです。この記事は atama plus Advent Calendar 2023 の14日目です。
昨日は@akira-2112によるMakefileを使った手順書レスな開発環境構築 でした。こちらもぜひご覧ください。
この記事ではatama plusでIonic Frameworkをv7へupdateした時のことについて紹介します。まずは、update前のatama＋アプリの状況の紹介から始めて、実際にupdateを行ったときのチームの体制やスケジュール、工夫した点、良かった点について紹介していきます。
そして最後に、これから取り組んでいきたいことについても少し触れてみたいと思います。
この記事が、Ionic Frameworkを使っている皆さんの参考になれば幸いです！
前提
まず、atama＋アプリの状況の紹介を行います。
規模感
atama plusでは、AI教材 atama＋ を開発・提供しています。
AI教材 atama＋は、生徒向けと先生向けのアプリケーションを含む、複数のアプリケーションから構成されています。
ソースコードの規模を具体的に示すために、clocを使用してコードの量を計測しました。その結果は以下の通りです：
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
JSON 205 167 0 432544
TypeScript 2237 23216 3661 147500
HTML 615 708 174 30550
SCSS 610 4244 540 24708
...
コンポーネント数は分け方に依存しますが、約900コンポーネント存在しています。(@Componentデコレータをgrepした数)
ライブラリのupdate状況
atama plusでは、技術的負債の解消・ライブラリのupdateなどを主に行うKaizenチームというチームが存在しており、フロントエンド周りのライブラリのupdate状況は以下のようになっていました。
- 毎年ionic のバージョンアップに追従している
-
ion-virtual-scrollは事前にcdk-virtual-scroll-viewportを使うようにしていた - Angular14の状態でv7 updateを行い、Angular15にはその後すぐにupdateを行った
今回のv7へのupdateは後述する属人性を減らす目的でKaizenチームとは別の一時的なチームを結成して実施しました。適切にライブラリのupdateに追従できているので、v6からv7にupdateすることだけに集中できて助かりました。
updateの実施
次に、実際にupdateを実施したときのチームの体制やスケジュール、工夫した点、良かった点について紹介していきます。
チーム体制
前述したように、今回はKaizenチームではなく、いつもは新機能の開発などを主に担当しているチームから一時的なチームを結成してupdate対応を行いました。
実際のチーム体制は以下の通りです。
- エンジニア 4名
- updateを実施・発生したバグ修正する人 2名
- レビュワー 1名
- PM的な動きをする人 1名
- デザイナー 1名
- QA 2名
スケジュール
update作業は以下のようなスケジュールで実施しました。
| 5/31〜6/6 | 6/7〜6/13 | 6/14〜6/20 | 6/21〜6/27 | 6/28〜7/4 | |
|---|---|---|---|---|---|
| エンジニア | 1人が先行してバージョンを上げて各appが起動できるようにする | リグレッションテストで出てきたupdateに伴って発生したバグを適宜修正 | ~ | ~ | ~ |
| QA | ビジュアルリグレッションテストの作成を含む全体的なリグレッションテストの実施 | ~ | リグレッションテストで洗い出されたバグの修正確認 | ~ | |
| デザイナー | updateに伴うUIの差分の修正要否を適宜判断 | ~ | ~ | ~ |
また、6/21〜は新規リリースを停止し、入れ違いでupdateによるバグ等が混入しないようにしました。
updateにおける具体的な対応内容
具体的な対応内容はプロダクトの作りや対応の仕方に依存するので参考程度ですが、今回のプロジェクトではこのような規模感でした。
機能に関するバグチケット：29件
UIに差分があるデザイン調整チケット：87件(その中の19件は許容として対応なし)
PR全体の規模：
といっても差分の多くはpackage-lock.json なので、プロダクトコードの修正は数百行程度です。
大抵は Updating from Ionic 6 to 7とBreaking Changesを読めば対応できました。
一部Issueを見たり、詳しく知りたいところはソースコードを読んだりもしていました。
工夫した点・良かった点
工夫した点・良かった点を紹介します。よければ参考にしてみてください。
初期にupdate後のバージョンで自動テストを通過させる
update作業の初期にQAが作成した自動ビジュアルリグレッションテストを主要導線に対して実施しました。これにより全体でどの程度バグが検出されそうかを想定しながら進めることができました。
初期にBreaking Changesの読合せを実施する
update作業の初期にエンジニアとQA間でBreaking Changesの読み合わせを行うことで、どのコンポーネントにバグが出やすそうかなど、その後の動き方をイメージしやすくなり、効率化・抜け漏れの低減に貢献しました。
デザイナーと協業する
修正に際してUI変更が生じることがありましたが、デイリー等の場でその変更が許容できるかの判断を下せる人と一緒のチームでupdate作業を行えると、非常に効率的に修正を進めることができました。
軽微な修正はリリース停止解除後に対応する
↑とも関連しますが、デザイナーに相談して「後々は修正を行いたいが、一旦そのままでリリースしても問題ない」とトリアージされたものに関してはリリース停止解除後に対応することで、updateに伴ってプロダクトのリリースが停止されてしまう期間を最小限にすることができました。
update作業の属人性を減らした
今ままでは前述したKaizenチームの対応が必須であり、アップデート対応には一定の属人性がありましたが、今回のupdate対応は他チームから一時的なチームを結成してupdate対応を行いました。これによりKaizenチームへの依存はほぼなくなり、update作業を行うハードルが低くなりました。
展望(これからやりたいこと)
最後に展望としてこれから取り組んでいきたいことをいくつか紹介します。
新しいform syntax への移行
Ionic7から、Formコンポーネント類がシンプルに記述できるようになりました。今回のupdate対応では全ての使用箇所を新しい記述に変更することはできなかったので、移行を進めていきたいと思っています。
参考：
普段からIonicのマイナーバージョンに追従する
今まではupdate対応に属人性がある + 影響範囲が大きくエンジニアとQAの負担・工数が大きく、マイナーバージョンがリリースされる度に追従はしてこれませんでした。
今回一時的なチームを結成してupdate対応を行ったことで、属人性をある程度排除出来たので、取り組みやすくなりました。
さらに自動のリグレッションテストも充実してきたため、少ない工数で普段からIonicのマイナーバージョンに追従できるようにしていきたいと思っています。
まとめ
以上atama plusでIonic Frameworkをv7へupdateしたプロジェクトについて紹介を行いました。
明日のアドベントカレンダー15日目は@ikasumi_wtが社内でカンファレンスを企画運営した時の知見について書かれます！お楽しみに。
ここまで読んでいただきありがとうございました！
Discussion