アプリケーションの更新
Electronアプリケーションに自動更新を提供するには、いくつかの方法があります。最も簡単で公式にサポートされている方法は、ビルトインのSquirrelフレームワークとElectronのautoUpdaterモジュールを利用することです。
クラウドオブジェクトストレージ（サーバーレス）の使用
シンプルなサーバーレス更新フローの場合、ElectronのautoUpdaterモジュールは、最新のリリースメタデータを含む静的ストレージURLを指定することで、更新の有無を確認できます。
新しいリリースが利用可能になった場合、このメタデータはリリース自体とともにクラウドストレージに公開する必要があります。メタデータのフォーマットは、macOSとWindowsで異なります。
リリースメタデータの公開
Electron Forgeを使用すると、macUpdateManifestBaseUrl（macOS）とremoteReleases（Windows）を使用して、ZIP Maker（macOS）とSquirrel.Windows Maker（Windows）からメタデータアーティファクトを公開することにより、静的ファイルストレージ更新を設定できます。
エンドツーエンドの例については、ForgeのS3からの自動更新ガイドを参照してください。
手動公開
macOSでは、Squirrel.Macは次のJSON形式の`releases.json`ファイルを読み取ることで更新を受信できます。
{
"currentRelease": "1.2.3",
"releases": [
{
"version": "1.2.1",
"updateTo": {
"version": "1.2.1",
"pub_date": "2023-09-18T12:29:53+01:00",
"notes": "Theses are some release notes innit",
"name": "1.2.1",
"url": "https://mycompany.example.com/myapp/releases/myrelease"
}
},
{
"version": "1.2.3",
"updateTo": {
"version": "1.2.3",
"pub_date": "2024-09-18T12:29:53+01:00",
"notes": "Theses are some more release notes innit",
"name": "1.2.3",
"url": "https://mycompany.example.com/myapp/releases/myrelease3"
}
}
]
}
Windowsでは、Squirrel.Windowsはビルドプロセス中に生成されたRELEASESファイルから読み取ることで更新を受信できます。このファイルには、更新する`.nupkg`デルタパッケージの詳細が記述されています。
B0892F3C7AC91D72A6271FF36905FEF8FE993520 electron-fiddle-0.36.3-full.nupkg 103298365
これらのファイルは、アプリケーションのプラットフォームとアーキテクチャを認識したフォルダー構造の下、リリースと同じディレクトリに存在する必要があります。
例：
my-app-updates/
├─ darwin/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-darwin-x64.zip
│ │ ├─ my-app-1.1.0-darwin-x64.zip
│ │ ├─ RELEASES.json
│ ├─ arm64/
│ │ ├─ my-app-1.0.0-darwin-arm64.zip
│ │ ├─ my-app-1.1.0-darwin-arm64.zip
│ │ ├─ RELEASES.json
├─ win32/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-win32-x64.exe
│ │ ├─ my-app-1.0.0-win32-x64.nupkg
│ │ ├─ my-app-1.1.0-win32-x64.exe
│ │ ├─ my-app-1.1.0-win32-x64.nupkg
│ │ ├─ RELEASES
リリースメタデータの読み取り
メタデータを使用する最も簡単な方法は、autoUpdaterを設定し、ネイティブダイアログでユーザーにプロンプトを表示する、ドロップインNode.jsモジュールであるupdate-electron-appをインストールすることです。
静的ストレージ更新の場合、`updateSource.baseUrl`パラメーターをリリースメタデータファイルを含むディレクトリに設定します。
const { updateElectronApp, UpdateSourceType } = require('update-electron-app')
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-bucket.s3.amazonaws.com/my-app-updates/${process.platform}/${process.arch}`
}
})
update.electronjs.orgの使用
Electronチームは、Electronアプリが自己更新に使用できる、無料かつオープンソースのウェブサービスであるupdate.electronjs.orgを維持しています。このサービスは、次の基準を満たすElectronアプリ向けに設計されています。
- アプリはmacOSまたはWindowsで実行されます。
- アプリには公開GitHubリポジトリがあります。
- ビルドはGitHub Releasesに公開されます。
- ビルドはコード署名されています **（macOSのみ）**
このサービスを使用する最も簡単な方法は、update.electronjs.orgで使用するために事前に構成されたNode.jsモジュールであるupdate-electron-appをインストールすることです。
お好みのNode.jsパッケージマネージャーを使用してモジュールをインストールします。
- npm
- Yarn
npm install update-electron-app
yarn add update-electron-app
次に、アプリのメインプロセスファイルからアップデータを実行します。
require('update-electron-app')()
デフォルトでは、このモジュールはアプリの起動時に、その後10分ごとに更新を確認します。更新が見つかった場合、バックグラウンドで自動的にダウンロードされます。ダウンロードが完了すると、ユーザーがアプリを再起動できるダイアログが表示されます。
設定をカスタマイズする必要がある場合は、update-electron-appにオプションを渡すか、更新サービスを直接使用できます。
その他の更新サービスの使用
プライベートなElectronアプリケーションを開発している場合、またはGitHub Releasesにリリースを公開していない場合は、独自の更新サーバーを実行する必要がある場合があります。
ステップ1：更新サーバーの展開
ニーズに応じて、次のいずれかを選択できます。
- Hazel – Vercelで無料で展開できる、プライベートまたはオープンソースアプリ向けの更新サーバーです。GitHub Releasesから取得し、GitHubのCDNを活用します。
- Nuts – GitHub Releasesも使用しますが、アプリの更新をディスクにキャッシュし、プライベートリポジトリをサポートします。
- electron-release-server – リリースを処理するためのダッシュボードを提供し、GitHubを起点とするリリースを必要としません。
- Nucleus – Atlassianが維持するElectronアプリ向けの完全な更新サーバーです。複数のアプリケーションとチャネルをサポートし、静的ファイルストアを使用してサーバーコストを最小限に抑えます。
更新サーバーを展開したら、ElectronのautoUpdaterモジュールを使用して、アプリコードを操作して更新を受信および適用できます。
ステップ2：アプリでの更新の受信
まず、メインプロセスコードに必要なモジュールをインポートします。次のコードは、サーバーソフトウェアによって異なる場合がありますが、Hazelを使用する場合、説明どおりに機能します。
以下のコードがパッケージ化されたアプリでのみ実行され、開発時には実行されないようにしてください。app.isPackaged APIを使用して環境を確認できます。
const { app, autoUpdater, dialog } = require('electron')
次に、更新サーバーフィードのURLを作成し、autoUpdaterにそのURLを知らせます。
const server = 'https://your-deployment-url.com'
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
最後のステップとして、更新を確認します。以下の例では、1分ごとに確認します。
setInterval(() => {
autoUpdater.checkForUpdates()
}, 60000)
アプリケーションがパッケージ化されると、公開する新しいGitHub Releaseごとに更新を受信します。
ステップ3：更新が利用可能な場合のユーザーへの通知
アプリケーションの基本的な更新メカニズムを構成したら、更新がある場合にユーザーに通知されるようにする必要があります。これはautoUpdater APIイベントを使用して実現できます。
autoUpdater.on('update-downloaded', (event, releaseNotes, releaseName) => {
const dialogOpts = {
type: 'info',
buttons: ['Restart', 'Later'],
title: 'Application Update',
message: process.platform === 'win32' ? releaseNotes : releaseName,
detail:
'A new version has been downloaded. Restart the application to apply the updates.'
}
dialog.showMessageBox(dialogOpts).then((returnValue) => {
if (returnValue.response === 0) autoUpdater.quitAndInstall()
})
})
また、エラーが処理されていることを確認してください。`stderr`にログ記録する例を以下に示します。
autoUpdater.on('error', (message) => {
console.error('There was a problem updating the application')
console.error(message)
})
autoUpdateによって行われる要求は直接制御できないため、（更新サーバーが認証の背後にある場合など）処理が困難な状況が発生する可能性があります。`url`フィールドは`file://`プロトコルをサポートしているため、多少の努力で、ローカルディレクトリから更新を読み込むことでサーバー通信のアスペクトを回避できます。これがどのように機能するかについての例を以下に示します。
更新サーバーの仕様
高度な展開ニーズの場合、Squirrel互換の更新サーバーを独自にロールアウトすることもできます。たとえば、パーセンテージベースのロールアウト、異なるリリースチャネルを通じたアプリの配布、または認証チェックの背後にある更新サーバーの配置を行うことができます。
Squirrel.WindowsとSquirrel.Macクライアントは異なるレスポンス形式を必要としますが、`process.platform`の値に応じて異なるエンドポイントに要求を送信することで、両方のプラットフォームに単一のサーバーを使用できます。
const { app, autoUpdater } = require('electron')
const server = 'https://your-deployment-url.com'
// e.g. for Windows and app version 1.2.3
// https://your-deployment-url.com/update/win32/1.2.3
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
Windows
Squirrel.Windows クライアントは、最新の利用可能なビルドのRELEASES アーティファクトを、エンドポイントの/RELEASES サブパスでアップデートサーバーが返すことを期待しています。
例えば、フィードURLがhttps://your-deployment-url.com/update/win32/1.2.3である場合、https://your-deployment-url.com/update/win32/1.2.3/RELEASESエンドポイントは、提供するバージョンのRELEASESアーティファクトの内容を返す必要があります。
B0892F3C7AC91D72A6271FF36905FEF8FE993520 https://your-static.storage/your-app-1.2.3-full.nupkg 103298365
Squirrel.Windows は、現在のアプリがRELEASESで返されたバージョンにアップデートする必要があるかどうかを比較チェックするため、アップデートが利用できない場合でもレスポンスを返す必要があります。
macOS
アップデートが利用可能な場合、Squirrel.Mac クライアントは、フィードURLのエンドポイントでJSONレスポンスを期待します。このオブジェクトには、アプリアップデートのZIPアーカイブにマップされる必須のurlプロパティがあります。オブジェクト内の他のすべてのプロパティはオプションです。
{
"url": "https://your-static.storage/your-app-1.2.3-darwin.zip",
"name": "1.2.3",
"notes": "Theses are some release notes innit",
"pub_date": "2024-09-18T12:29:53+01:00"
}
アップデートが利用できない場合、サーバーは204 No Content HTTPレスポンスを返す必要があります。