Electron Vs Enterprise

エレクトロン対エンタープライズ
技術に感電した63日 (営業日)
html5jウェブプラットフォーム部
第11回勉強会

“
本日のお話
エレクトロンに感じた魅力
Electronは産業を支えるに魅力的なプラットフォームか？
実際の導入について
実際に導入しての詰まりどころ、
手離れ具合と導入コストが何処にかかり、何処を省略すべきか？
効果の見込めるユースケース
どのようなユースケースで導入効果が見込めるか？

本日のお話概要
1. 導入についての検討
2. 開発から運用まで
1. 開発編
2. テスト＆ビルドインフラ編
3. 運用編
3. 社内でエレクトロンを使うとき
4. ふりかえり

導入編
introduction chapter
アプリ怪獣エレクトロン登場
感電度

導入について
未知の技術をいきなりぶっこむのは禁忌
エンタープライズでのIT活用はエンジニアリングを中心として利益
をあげているのではなく、別の産業もしくはサービスサイエンス的
なITを補助的に活用することが主になる。
責任を持てるエンジニアが居たとしても、
運用でその一部のエンジニアに負荷が集中ないし、俗人化するよう
な状況を残さないようにすることが大切。

導入について
責任を最後まで持てるのか？
最低でも損益分岐を迎えられるまで運用できるのか？
手離れしやすいものか？
CI/CDインフラの構築についてどれだけできるのか？
該当技術の更新をキャッチアップできるか？
新機能やセキュリティアップデート等の追従にどれだけ
コストを裂かなければならないのか？

導入について
とはいえ・・・
手を拱いていては最後まで使う事は無いだろうし選択肢も
増えない
情報だけキャッチアップしたり、個人での検討・検証だけ
したものをいざ必要になった時に本番で使ってしまうと言
う事も負債製造スパイラルの開始になってしまう。
昔の人は便利な事を言いました。

検査と適応
Inspect
And
Adapt
問題があるなら
改善すればいいじゃない

導入について
個人手の検証
開発インフラへの適用と検査
CI/CDへの適用と検査
Businessバックエンドへの適用と検査
Businessフロントへの適用と検査
改善にElectronを使う
小さなところから使ってみる。
ダメならパージ(捨てれば)良い
改善できれば次のステップへ

開発から運用まで
Develop Testing Operator

開発編
Development chapter
感電度

開発に置けるElectron
Web開発プラットフォームが整っている場合、既存の資産がほぼ流用可能
作り方は古川氏、セキュリティは長谷川氏より前もってお話があるので割愛。
1. Web開発で得た知識、ノウハウ
2. JavaScript Library
3. Task runner (Gulp/Grunt)
4. End to End Testing
Chromeブラウザ固定
Input type=“xxx”が動作する。
Web Notificationが真の価値を発揮できる。

開発に置けるElectron
注意するところに注意すればそんなにハマらない
以下にだけ注意しておく必要がある。
1. Originが file://
2. Domを弄る系のライブラリ(JQuery, Angular)の場合
特殊なエスケープが必要
3. Mainとrenderの２つの処理が動いてる
4. npm –g electron
5. Windowsは7から

検証編テスト&ビルドインフラ
Testing chapter
感電度

検証に置けるElectron
〜無駄死の章〜
目標
開発〜リリースまでの手順をなるべく省力化・
自動化し、運用監視含めて手離れを良くしたい。
具体的には
1. Webと同等の開発ライフサイクル
2. モニタリング＆死活監視による問題と障害検知
3. リリースのオートメーション化と自動テスト

Web開発と同等の開発ライフサイクル
既存のWeb開発と同じ
Gulp/Gruntで構築するのは割と簡単にできる
ほとんどが既存のWeb開発のノウハウを流用可能
一点違うところはライブリロード開発部分
Renderプロセスは既存のLivereload開発と同じだが、
Mainプロセス側に修正を入れた場合は再起動を行う必要が有る。
手軽に導入するなら @Quramy氏の`electron-connect`と言う物も

モニタリングと死活監視
Mainプロセスで監視、Updateサーバーをそのまま転用
既存のSPAの要なモニタリングではRenderプロセスしかモニタリング
できない為、アプリケーション起動時のMainプロセスから
Web Socket経由でのモニタリングを行う事に。
後で説明する自動更新用のサーバーに監視用APIを追加するだけで済
むため、既存のWebインフラが有れば簡単に導入が可能。

機能テスト自動化を目指す調査に時間がかかった。
(無駄に時間を食ったとも言う)
Electronは複数の技術Webが絡まっている為、
それぞれの部分に対するCross Platformテストの構築が難しい
自動化するにあたって、投資とリターンの分岐点はどこか探る必要があった。
機能技術テスト技術
Render ブラウザ(Chrome) KarmaJS + electron
main NodeJS Jasmine + electron
Menu Native Coded / RobotJS
Installer/Updater Squirrel / NSIS Coded
リリース自動化の為の自動テスト化

計画した自動テストの内訳 (導入コスト検証)
Render
Unit Testing
Main
Unit Testing
Integration
Testing
(E2E)
acceptance
Testing
Unit Testing ( Render / Main )
カバレッジを取りつつ部品の機能をテストする
Functional Testing
Renderプロセスの振る舞いをテストする
Integration Testing
Render + Main合わせないと確認できない系、メニューのテスト
Acceptance Testing
サービスとしての機能を満たすか確認する。
インストール、アップデート死活監視の機能チェックはここで
Functional
Testing (E2E)

以下のような構成で自動テスト化してみた所
結論として「 Web Driverのテストであれば導入コストが安い」
テストフェーズ Run Pint Cost 備考
Unit (Render) Karma 中 Karma + electronで実行
Unit (Main) NodeJS 中- Spawnでelectron + jasmineを実行
Functional Protractor 小 WDが使えるのでProtractorで
Integration Protractor 中+ Protractor + RobotJS + Node.spawn
Acceptance Coded
Robot FW
大 Windowsの場合インストール後にしかテ
ストできない機能が割と有る。
リリースオートメーション化の為の自動テスト

運用編
Operation chapter
感電度

運用に置けるElectron
自動Update
Squirrel.Windows の導入は手軽
認証回りはGatekeeperとcode signing認証（お金がかかる・・・）
後はネットワークインフラが整えば準備完了
既存のWebサーバーにAPIを追加するだけで導入可能
基本的に必要なサーバー側機能は次の通り
1. 自動更新をチェックするAPI
2. 更新用ファイルができるURL
macの場合はzipファイル、windowの場合は Nuget形式
3. 余裕があれば死活監視とモニタリング用API

運用に置けるElectron
Electron本体の更新の早さ
更新速度はかなり速い
手放し運用はできないが、不安定/放置されている技術ではない為逆に安心
感はある。
どちらかと言うと前章でお話しした検証回りの自動化部分をやりすぎると
そちらの改善と追従に時間を取られる、検証の自動化はほどほどが良さそう
0.34.0 2015/10/16
0.35.0 2015/11/16
0.36.0 2015/12/11
0.36.10 2016/03/05
0.36.5 2016/01/22
0.36.6 2016/01/29
0.36.7 2016/01/30
0.36.8 2016/02/19
0.36.9 2016/02/26
0.36.10 2016/03/05
メジャーバージョンアップマイナーバージョンアップ

社内でエレクトロン
Corporate of the Electron

社内でElectron
同様のインフラが構築済みの場合
無理にエレクトロンを利用する必要は無い
Javaや.Netでこれまで話したアプリ配布インフラは構築可能です。
すでに同じような開発インフラが出来ているのなら無理して置き換え
る物ではありません。
フロントエンジニアのリソースが余っているのなら
バックのエンジニアが足りなくフロント(Web)エンジニアのリソース
が余ってる場合は、フロントエンジニアにクライアントアプリを作成
するインフラが提供できるので、一考の価値はある・・・かもしれな
い
（フロントエンジニアが余ってるならうちにもリソース分けて欲しい・・・）

社内でElectron
まだ同じようなインフラが出来ていない場合
まずは社内に居るエンジニアの割合で
社内にWebエンジニアが居るのであればElectronを取り入れる価値は
十分ある。
しかし他の技術でも同等のインフラは構築可能なので、社内に別の技
術で責任を持てるエンジニアが居るのなら、そのエンジニアと要相談。
既存Webシステムの機能拡張として
既存のサーバーに対して自動更新と更新ファイルダウンロードのAPI
を追加するだけで導入可能。
（あればインストーラをダウンローするAPIなども）
既存Webで諦めていた機能が実現可能になる。
（WebクライアントでのExcel取り込み・出力、AcriveDirectory連携など）

社内でElectron
導入に効果がありそうなところ
常駐アプリケーション
通知領域に常駐するアプリケーションを作成可能
既存Webシステムの延長
インフラ的には更新通知とインストーラー・更新ファイルDLを追加す
るだけなので既存WebシステムのNative拡張としての導入が容易
XULRunnerと同様の用途
Webシステムにおけるブラウザの固定化
Browser Extensionで無理矢理実現していた業務
WebシステムのNative連携を行う場合など

社内でElectron
やめたほうが良いところ
負の既存資産を置き換えするのは現実的ではありません。
既存 XULRunner アプリを置き換える
多分動きません。
どうしてもやりたい場合はテスト頑張りましょう
既存WebシステムのElectron化
同上
サポートブラウザにChromeが有れば動作するかも
Windows 7以前のOS対応
ElectronはWindows 7以上のみサポート

まとめ
Electron Vs Enterprise
開発良い良い運用怖い
自動化構築は割と大変、ある程度で重要な機能と自動化投資のバラン
スが大切
バグやセキュリティアップデートでElectron本体の更新はかなり早い
ため責任と覚悟が必要
既存資産の置き換えには向かない
既存Web資産をElectron化する場合は素直に作り替える位を考えて
基本は新規で作るものに向いているが、既存システムの部分拡張とし
て使え無い事も無い。
内製であるなら有用
上記をわきまえた上で、内製するのなら適用出来そうなユースケース
は割とある
納品のある受託開発のような売り切り型では顧客に負の資産を押し付
ける事になるか、保守コストが嵩む。

まとめ
個人的に…
業務用デスクトップアプリを作る技術として
.NET(UWP/WPF) >>> Electron >>> JavaFx >= その他UI技術
開発については楽だけれどテストや運用、デプロイ回りを考えると.net系技術の
方が手離れが良い
Electronに置ける利点はクロスプラットフォームと言う点だけれど、エンタープ
ライズの場合殆どWindowsなので上記のような感想に
簡単な開発からリリースインフラ構築までは低コスト
いきなりNativeアプリ目的として使うのはハードルが高いと思う人は
低コスト導入できるXULRunnerのような利用ブラウザの固定化目的で使うのがユ
ースケースとして手軽でオススメ
外向けに作るならエレクトロン
外向けに作る場合はUIの作成に手慣れているフロント(Web)エンジニアを使わな
い手は無いと思う、
外向けにNative Clientを作る場合にWebエンジニアが活躍できるのが、他の技術
よりもElectronの方が優れている所かも。

酒巻瑞穂
グロースエクスパートナーズ（株）所属
Frontend Engineer
I am here because I love to programing.
https://github.com/MSakamaki
Thanks!

Electron Vs Enterprise

Recommended

Recommended

More Related Content

Similar to Electron Vs Enterprise

Similar to Electron Vs Enterprise (20)

More from Mizuho Sakamaki

More from Mizuho Sakamaki (8)

Electron Vs Enterprise