社内電話アプリをChrome拡張機能からElectronにリプレースした話

f:id:y-kure-lvgs:20201228154941p:plain

はじめに

こんにちは!エンジニアの呉です! 今回は社内で開発している電話アプリについて、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 ページ単位単位でのコンポーネント定義

■リリースフロー

f:id:y-kure-lvgs:20201228154425p:plain
リリースフロー

これまで他のプロジェクトでは、CircleCIを使ったリリースの自動化をしていましたが、今回はGitHub Actionsを使ったリリース方法を採用しました。

理由としては、

  1. 社内でElectronを使ったプロジェクトが多く発足する可能性を考慮し、プロジェクト独自のリリースフローで良いと判断
  2. GitHub Actionsのワークフローを定義のみで設定作業のコストを削減
  3. CircleCIのmacOSビルド環境(executor)を追加で契約する必要があったため、ランニングコストを削減

よかった点

今回電話アプリの開発を実際に担当している身として、前述の問題点に対してどうすべきなのか、どうしたらやりやすくなるのかをエンジニアサイドから考えた上での行動に起こしました。

■運用保守コスト

結果として、リプレースによる利用者の満足度を向上させるようなダイレクトなインパクトはありませんでしたが、エンジニアサイドの心理的安心感や運用保守コストダウンにより、間接的に利用者に機能提供するまでの開発効率を向上することができました。

■スキル

ElectronやGitHub Actionsなど社内でもあまり導入実績のない技術に対して挑戦することで、個人の成長を実感することができました!

■意思決定

今回のリプレースの提案に対しても「イイじゃん!イイじゃん!」と共感してもらった上で、その場で「じゃあいつまでにできそう?」とスピード感に若干驚きました(笑)

ボトムアップの提案に対してもスピーディに対応し、承認までの間隔が短く、提案することに対して億劫にならない環境だなーと私個人としてとても印象に残りました。

大変だった点

…ここまで良いことばかり書いてきましたが、もちろん良いことだけではありませんでした。

■Twilio

元々前任者がベースを開発していたこともあり、全容を完璧に把握できていたわけではなかったので、動作が変わらないように全体を見渡す時間がとてつもなくかかってしまいました。

■Appleの公証

macOSを利用している方もいるため、Appleの公証(アプリ署名)を行う必要がありました。

Apple Developer Programからの証明書発行、発行した証明書を用いてビルド・リリースの自動化で苦戦をしました。

最終的にはelectron-notarizeを使うことで解決しました。

まとめ

いかがでしたでしょうか?

社内のカイゼン事例として、社内電話アプリのChrome拡張機能からElectronにリプレースした話をご紹介いたしました。

今回エンジニアによるボトムアップからの提案に対してスピーディに実現ができたことが素直にとても嬉しかったです。

みなさんも「やりたい!」と思ったことをまずは声に出してみるところから始めてみてはいかがでしょうか。

We are Hiring

f:id:y-kure-lvgs:20201228154849p:plain

レバレジーズでは、一緒に今をより良くしていく仲間を募集しています。

弊社に少しでも興味を持っていただいた方は是非ご連絡いただけると幸いです。

https://recruit.jobcan.jp/leverages/