Embed Size (px)
Citation preview
エレクトロン 対 エンタープライズ技術に感電した 63 日 ( 営業日 )
html5j ウェブプラットフォーム部第 11 回勉強会
本日のお話introduction
“本日のお話
エレクトロンに感じた魅力Electron は産業を支えるに魅力的なプラットフォームか？
実際の導入について実際に導入しての詰まりどころ、手離れ具合と導入コストが何処にかかり、何処を省略すべきか？
効果の見込めるユースケースどのようなユースケースで導入効果が見込めるか？
本日のお話概要
1. 導入についての検討2. 開発から運用まで
1. 開発編2. テスト＆ビルドインフラ編3. 運用編
3. 社内でエレクトロンを使うとき4. ふりかえり
導入編introduction chapter
アプリ怪獣エレクトロン登場
感電度
導入について
未知の技術をいきなりぶっこむのは禁忌
エンタープライズでの IT 活用はエンジニアリングを中心として利益をあげているのではなく、別の産業もしくはサービスサイエンス的な IT を補助的に活用することが主になる。責任を持てるエンジニアが居たとしても、運用でその一部のエンジニアに負荷が集中ないし、俗人化するような状況を残さないようにすることが大切。
導入について
責任を最後まで持てるのか？最低でも損益分岐を迎えられるまで運用できるのか？
手離れしやすいものか？CI/CD インフラの構築についてどれだけできるのか？
該当技術の更新をキャッチアップできるか？新機能やセキュリティアップデート等の追従にどれだけコストを裂かなければならないのか？
導入について
とはいえ・・・手を拱いていては最後まで使う事は無いだろうし選択肢も増えない
情報だけキャッチアップしたり、個人での検討・検証だけしたものをいざ必要になった時に本番で使ってしまうと言う事も負債製造スパイラルの開始になってしまう。
昔の人は便利な事を言いました。
検査と適応
InspectAndAdapt問題があるなら改善すればいいじゃない
導入について
個人手の検証
開発インフラへの適用と検査
CI/CD への適用と検査
Business バックエンドへの適用と検査
Business フロントへの適用と検査
改善に Electron を使う
小さなところから使ってみる。ダメならパージ ( 捨てれば ) 良い改善できれば次のステップへ
導入について
個人手の検証
開発インフラへの適用と検査
CI/CD への適用と検査
Business バックエンドへの適用と検査
Business フロントへの適用と検査
改善に Electron を使う
小さなところから使ってみる。ダメならパージ ( 捨てれば ) 良い改善できれば次のステップへ
開発から運用まで
Develop Testing Operator
開発編Development chapter
アプリ怪獣エレクトロン登場
感電度
開発に置ける ElectronWeb 開発プラットフォームが整っている場合、既存の資産がほぼ流用可能作り方は古川氏、セキュリティは長谷川氏より前もってお話があるので割愛。
1. Web 開発で得た知識、ノウハウ2. JavaScript Library3. 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 electron5. Windows は 7 から
検証編テスト & ビルドインフラTesting chapter
アプリ怪獣エレクトロン登場
感電度
検証に置ける Electron〜無駄死の章〜
目標開発〜リリースまでの手順をなるべく省力化・自動化し、運用監視含めて手離れを良くしたい。
具体的には
1. Web と同等の開発ライフサイクル2. モニタリング＆死活監視による問題と障害検知3. リリースのオートメーション化と自動テスト
俺の屍
を
越え
てゆ
け
検証に置ける ElectronWeb 開発と同等の開発ライフサイクル
既存の Web 開発と同じGulp/Grunt で構築するのは割と簡単にできるほとんどが既存の Web 開発のノウハウを流用可能
一点違うところはライブリロード開発部分Render プロセスは既存の Livereload 開発と同じだが、Main プロセス側に修正を入れた場合は再起動を行う必要が有る。
手軽に導入するなら @Quramy 氏の `electron-connect` と言う物も
検証に置ける Electronモニタリングと死活監視
Main プロセスで監視、 Update サーバーをそのまま転用既存の SPA の要なモニタリングでは Render プロセスしかモニタリングできない為、アプリケーション起動時の Main プロセスからWeb Socket経由でのモニタリングを行う事に。
後で説明する自動更新用のサーバーに監視用 API を追加するだけで済むため、既存の Web インフラが有れば簡単に導入が可能。
検証に置ける Electron機能テスト自動化を目指す調査に時間がかかった。 ( 無駄に時間を食ったとも言う )
Electron は複数の技術 Web が絡まっている為、それぞれの部分に対する Cross Platform テストの構築が難しい自動化するにあたって、投資とリターンの分岐点はどこか探る必要があった。
機能 技術 テスト技術
Render ブラウザ (Chrome) KarmaJS + electron
main NodeJS Jasmine + electron
Menu Native Coded / RobotJS
Installer/Updater Squirrel / NSIS Coded
リリース自動化の為の自動テスト化
検証に置ける Electron計画した自動テストの内訳 ( 導入コスト検証 )
RenderUnit Testing
Main Unit Testing
IntegrationTesting(E2E)
acceptanceTesting
Unit Testing ( Render / Main )カバレッジを取りつつ部品の機能をテストするFunctional TestingRender プロセスの振る舞いをテストするIntegration TestingRender + Main 合わせないと確認できない系、メニューのテストAcceptance Testingサービスとしての機能を満たすか確認する。インストール、アップデート死活監視の機能チェックはここで
FunctionalTesting (E2E)
検証に置ける 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 CodedRobot FW
大 Windows の場合インストール後にしかテストできない機能が割と有る。
リリースオートメーション化の為の自動テスト
運用編Operation chapter
アプリ怪獣エレクトロン登場
感電度
運用に置ける Electron自動 Update
Squirrel.Windows の導入は手軽認証回りは Gatekeeper と code signing認証（お金がかかる・・・）後はネットワークインフラが整えば準備完了
既存の Web サーバーに API を追加するだけで導入可能基本的に必要なサーバー側機能は次の通り
1. 自動更新をチェックする API2. 更新用ファイルができる URL
mac の場合は zip ファイル、 window の場合は Nuget形式3. 余裕があれば死活監視とモニタリング用 API
運用に置ける ElectronElectron 本体の更新の早さ
更新速度はかなり速い手放し運用はできないが、不安定 /放置されている技術ではない為逆に安心感はある。どちらかと言うと前章でお話しした検証回りの自動化部分をやりすぎるとそちらの改善と追従に時間を取られる、検証の自動化はほどほどが良さそう
0.34.0 2015/10/160.35.0 2015/11/160.36.0 2015/12/110.36.10 2016/03/05
0.36.5 2016/01/220.36.6 2016/01/290.36.7 2016/01/300.36.8 2016/02/190.36.9 2016/02/260.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以上のみサポート
まとめSummary
まとめElectron Vs Enterprise
開発良い良い運用怖い自動化構築は割と大変、ある程度で重要な機能と自動化投資のバランスが大切バグやセキュリティアップデートで Electron 本体の更新はかなり早いため責任と覚悟が必要
既存資産の置き換えには向かない既存 Web 資産を Electron 化する場合は素直に作り替える位を考えて基本は新規で作るものに向いているが、既存システムの部分拡張として使え無い事も無い。
内製であるなら有用上記をわきまえた上で、内製するのなら適用出来そうなユースケースは割とある納品のある受託開発のような売り切り型では顧客に負の資産を押し付ける事になるか、保守コストが嵩む。
まとめ個人的に…
業務用デスクトップアプリを作る技術として.NET(UWP/WPF) >>> Electron >>> JavaFx >= その他 UI 技術
開発については楽だけれどテストや運用、デプロイ回りを考えると .net系技術の方が手離れが良いElectron に置ける利点はクロスプラットフォームと言う点だけれど、エンタープライズの場合殆ど Windows なので上記のような感想に
簡単な開発からリリースインフラ構築までは低コストいきなり Native アプリ目的として使うのはハードルが高いと思う人は低コスト導入できる XULRunner のような利用ブラウザの固定化目的で使うのがユースケースとして手軽でオススメ
外向けに作るならエレクトロン外向けに作る場合は UI の作成に手慣れているフロント (Web) エンジニアを使わない手は無いと思う、外向けに Native Client を作る場合に Web エンジニアが活躍できるのが、他の技術よりも Electron の方が優れている所かも。
酒巻 瑞穂グロースエクスパートナーズ（株）所属
Frontend EngineerI am here because I love to programing. https://github.com/MSakamaki
Thanks!
