はじめに
こんにちは！エンジニアの呉です！ 今回は社内で開発している電話アプリについて、Chrome拡張機能からElectronへリプレースした話をご紹介します。
リプレースしたきっかけ
■問題点
社内で開発している電話アプリでは、いくつかの問題が顕在化していました。
- コードの見通し
- 電話という特異的な機能に加えて、Chrome拡張機能独自のお作法によりコードの見通しが悪くなっていた
- 手動リリース
- ウェブストアのダッシュボードから審査の申請をする必要がある
- リリースコントロールがしにくい
- Chrome拡張機能の自動更新が最大5hのタイムラグが生じる(chroniumの対象コード)
- ウェブストアの審査が介入するため、リリースが手間
■解決手段
今回これらの問題を解決する手段として、Electron + Vue.jsでリプレースをすることを決めました。
- コードの見通し
- 社内で知見の多いVue.jsを採用し、学習コストを低減
- 言語はTypeScriptを採用し、型宣言による開発効率、保守性の向上
- 表示のコンポーネント化、機能のモジュール化を行うことにより、それぞれの責務を明確にし、コード全体の見通しを向上
- 手動リリース
- GitHub Actionsを利用し、リリースを自動化
- リリースコントロールがしにくい
- electron-builderのelectron-updaterパッケージを使い、自動更新タイミングを自分でコントロールできるように解決
- AWS S3へのアップロードを行うだけのため、審査介入によるリリースコストダウン
出来上がったもの
今回出来上がったものを簡単なご紹介します。
■Electronアプリケーション
主なディレクトリ構成は以下の通りです。
src ├── assets ├── background ├── components ├── constants ├── models ├── plugins ├── router ├── services ├── store └── views
| ディレクトリ名 | 役割 |
|---|---|
| assets | グローバルで利用するCSSやフォント、ロゴなどのリソース |
| background | Electronアプリケーションのライフサイクル制御とプロトコル設定、バージョンチェックなど |
| components | 表示部品単位でのコンポーネント定義 |
| constants | 通話で利用する結果コードの定義や外部イベントの定数を定義 |
| models | APIや通話で利用する連絡先などのモデル定義と型定義 |
| plugins | API通信で利用するaxiosやGoogle OAuth、Slackなど外部ライブラリのラッパーを定義 |
| router | ページのルーティング定義 |
| services | 業務ロジックをサービス層として抽出し定義 |
| store | モジュール単位での状態管理とアクション定義 |
| views | ページ単位単位でのコンポーネント定義 |
■リリースフロー
これまで他のプロジェクトでは、CircleCIを使ったリリースの自動化をしていましたが、今回はGitHub Actionsを使ったリリース方法を採用しました。
理由としては、
- 社内でElectronを使ったプロジェクトが多く発足する可能性を考慮し、プロジェクト独自のリリースフローで良いと判断
- GitHub Actionsのワークフローを定義のみで設定作業のコストを削減
- CircleCIのmacOSビルド環境(executor)を追加で契約する必要があったため、ランニングコストを削減
よかった点
今回電話アプリの開発を実際に担当している身として、前述の問題点に対してどうすべきなのか、どうしたらやりやすくなるのかをエンジニアサイドから考えた上での行動に起こしました。
■運用保守コスト
結果として、リプレースによる利用者の満足度を向上させるようなダイレクトなインパクトはありませんでしたが、エンジニアサイドの心理的安心感や運用保守コストダウンにより、間接的に利用者に機能提供するまでの開発効率を向上することができました。
■スキル
ElectronやGitHub Actionsなど社内でもあまり導入実績のない技術に対して挑戦することで、個人の成長を実感することができました！
■意思決定
今回のリプレースの提案に対しても「イイじゃん！イイじゃん！」と共感してもらった上で、その場で「じゃあいつまでにできそう？」とスピード感に若干驚きました（笑）
ボトムアップの提案に対してもスピーディに対応し、承認までの間隔が短く、提案することに対して億劫にならない環境だなーと私個人としてとても印象に残りました。
大変だった点
…ここまで良いことばかり書いてきましたが、もちろん良いことだけではありませんでした。
■Twilio
元々前任者がベースを開発していたこともあり、全容を完璧に把握できていたわけではなかったので、動作が変わらないように全体を見渡す時間がとてつもなくかかってしまいました。
■Appleの公証
macOSを利用している方もいるため、Appleの公証（アプリ署名）を行う必要がありました。
Apple Developer Programからの証明書発行、発行した証明書を用いてビルド・リリースの自動化で苦戦をしました。
最終的にはelectron-notarizeを使うことで解決しました。
まとめ
いかがでしたでしょうか？
社内のカイゼン事例として、社内電話アプリのChrome拡張機能からElectronにリプレースした話をご紹介いたしました。
今回エンジニアによるボトムアップからの提案に対してスピーディに実現ができたことが素直にとても嬉しかったです。
みなさんも「やりたい！」と思ったことをまずは声に出してみるところから始めてみてはいかがでしょうか。
We are Hiring
レバレジーズでは、一緒に今をより良くしていく仲間を募集しています。
弊社に少しでも興味を持っていただいた方は是非ご連絡いただけると幸いです。
