Electron Vs Enterprise

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

2. 本日のお話 introduction

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

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

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

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

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

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

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

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

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

12. 開発から運用まで Develop Testing Operator

13. 開発編 Development chapter アプリ怪獣エレクトロン登場感電度

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

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

16. 検証編テスト&ビルドインフラ Testing chapter アプリ怪獣エレクトロン登場感電度

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

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

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

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

21. 検証に置けるElectron 計画した自動テストの内訳 (導入コスト検証) 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)

22. 検証に置けるElectron 以下のような構成で自動テスト化してみた所結論として「 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の場合インストール後にしかテストできない機能が割と有る。リリースオートメーション化の為の自動テスト

23. 運用編 Operation chapter アプリ怪獣エレクトロン登場感電度

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

25. 運用に置ける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 メジャーバージョンアップマイナーバージョンアップ

26. 社内でエレクトロン Corporate of the Electron アプリ怪獣エレクトロン登場

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

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

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

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

31. まとめ Summary

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

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

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

Electron Vs Enterprise

Mizuho Sakamaki

Electron Vs Enterprise