electron-release

Electron の本番ビルドとリリースガイド

このスキルでは、セキュリティ、信頼性、パフォーマンス、ユーザーからの信頼を重視しながら、Electron アプリケーションをビルド、署名、リリース、配布するためのエンタープライズグレードのベストプラクティスを紹介します。

クイックリファレンス

1. ビルド設定：electron-vite の本番設定、バンドルの最適化、ビルド前チェックについて説明します。
2. コード署名：Windows（EV 証明書）、macOS（Developer ID と公証）、Linux（GPG）向けのプラットフォーム固有の署名について説明します。
3. 自動更新：electron-updater の設定、段階的なロールアウト、更新テストについて説明します。
4. リリースワークフロー：マルチプラットフォームビルド向けの GitHub Actions CI/CD パイプラインについて説明します。
5. 配布：GitHub Releases、Cloudflare R2、またはプライベートサーバーでのホスティングについて説明します。

基本原則

• セキュリティを最優先：すべての本番ビルドにコード署名が必要です。macOS ビルドには公証が必要です。
• ビルド前の検証：ビルド前に必ず pnpm audit、pnpm run typecheck、pnpm run lint、pnpm run test を実行してください。
• セマンティックバージョニング：SemVer（MAJOR.MINOR.PATCH）に厳密に従ってください。
• 段階的なロールアウト：まず一部のユーザーにリリースし、その後段階的に拡大してください。

ビルド戦略

ビルド前チェックリスト

本番ビルドのたびに、以下を実施してください。

1. 依存関係に脆弱性がないか確認します：pnpm audit
2. コード品質を検証します：pnpm run typecheck && pnpm run lint
3. テストスイートを実行します：pnpm run test && pnpm run test:e2e
4. バンドルサイズを確認します：pnpm run build:analyzer
5. 環境設定を検証します

本番ビルドの最適化

• すべての console.log および debugger 文を削除します
• 使用されていない依存関係をツリーシェイクします
• ベンダーチャンク（React、UI ライブラリ）を分割します
• 画像とアセットを圧縮します
• 重要度の低いモジュールを遅延読み込みします
• 配布用のソースマップを無効にします（必要な場合は別途同梱します）
• 本番モードのビルドフラグを使用します

バンドルサイズの目標

コンポーネント	目標
メインプロセス	< 2 MB
レンダラー	< 5 MB
パッケージ全体	< 150 MB
インストールサイズ	< 250 MB

コード署名

Windows（EV 証明書が必要）

Microsoft は 2023 年 6 月以降、Extended Validation（EV）証明書を必須としています。

推奨：クラウドベースの署名（DigiCert KeyLocker または Azure Trusted Signing）を使用してください。

配布に自己署名証明書を使用しないでください。

macOS（Developer ID と公証）

以下の 2 段階で行います。

1. コード署名：Developer ID Certificate を使用します
2. 公証：Apple がマルウェアをスキャンします（配布に必須です）

主な要件：

• electron-builder の設定に hardenedRuntime: true を指定する
• 有効な entitlements.mac.plist
• APPLE_TEAM_ID、APPLE_ID、APPLE_APP_SPECIFIC_PASSWORD の環境変数

Linux（GPG）

リリース成果物に GPG で署名します。

gpg --detach-sign -u YOUR_KEY_ID dist/packages/*.AppImage
gpg --detach-sign -u YOUR_KEY_ID dist/packages/*.deb

自動更新の実装

electron-updater の設定

electron-builder.yml で公開プロバイダーを設定します。

publish:
  provider: github
  owner: your-username
  repo: your-repo
  releaseType: release

段階的なロールアウト戦略

更新を段階的に展開してリスクを軽減します。

• 1 日目：ユーザーの 10%
• 2 日目：ユーザーの 25%
• 3 日目：ユーザーの 50%
• 4 日目：ユーザーの 100%

問題が検出された場合：

• 同じバージョンを再リリースしないでください（ユーザーは更新を無視します）
• より高いバージョンをリリースします（例：1.0.1 -> 1.0.2）
• 重大なバグがある場合は、以前のバージョンへのロールバックを検討してください

自動更新のローカルテスト

ローカルテストには dev-app-update.yml を使用します。リリース前に更新サイクル全体をテストしてください。

リリースワークフロー

手動リリースチェックリスト

リリースタグを作成する前に：

• このバージョンに含まれるすべての PR をマージする
• package.json のバージョンを更新する
• CHANGELOG.md を更新する
• テストスイート全体を実行する
• バンドル解析を実行する
• ビルドをローカルでテストする
• アプリが起動し、基本機能が動作することを確認する
• 自動更新の仕組みをテストする

リリースの作成

git tag -a v1.2.3 -m "Release v1.2.3"
git push origin v1.2.3

GitHub Actions が以下を自動的に処理します。

1. Windows、macOS、Linux 向けのビルド
2. コード署名
3. 公証（macOS）
4. GitHub Release の作成
5. 成果物の公開

配布オプション

GitHub リリース（推奨）

• 無料で信頼性が高い
• 自動更新機能が標準でサポートされています
• バージョン管理
• リリースノート

Cloudflare R2

R2 エンドポイントを使用する S3 互換ストレージです。環境変数を設定してください。

• R2_BUCKET_NAME
• R2_ACCOUNT_ID
• R2_ACCESS_KEY_ID
• R2_SECRET_ACCESS_KEY
• UPDATE_FEED_URL

プライベートサーバー（汎用 HTTP）

HTTPS 経由で latest.yml、latest-mac.yml、およびすべてのアーティファクトを配信する必要があります。

セキュリティチェックリスト

リリース前に、以下を確認してください。

• 依存関係を監査済み（pnpm audit）
• コードにハードコードされたシークレットがない
• IPC チャネルを検証済み
• CSP を適切に設定済み
• コンテキスト分離を有効化済み
• レンダラーで Node 統合を無効化済み
• すべてのウィンドウでサンドボックスを有効化済み
• 自動更新をエンドツーエンドでテスト済み
• コード署名証明書が有効
• macOS アプリを公証済み
• すべての通信が HTTPS 経由
• ログやエラーメッセージに機密データが含まれていない

トラブルシューティング

問題	解決策
自動更新が開始されない	latest.yml が存在することを確認し、GitHub リリースの設定を確認してください
コード署名に失敗する	証明書を更新し、フィンガープリントを確認してください
Windows SmartScreen の警告が表示される	広く配布し、評価を得るために Microsoft に申請してください
macOS で「開発元を検証できません」と表示される	再度公証し、チーム ID と証明書を確認してください
アプリのダウンロードサイズが大きい	ANALYZE=true pnpm run build で分析し、圧縮を有効にしてください
本番環境で画面が真っ白になる	相対パス（base: './'）を使用し、ビルド出力を確認してください

検証チェックリスト

Electron のリリースに関するタスクを完了する前に、以下を確認してください。

• ビルド前チェック（監査、型チェック、リンティング、テスト）に合格している
• バンドルサイズが目標の範囲内である
• すべてのプラットフォームでコード署名を設定済み
• macOS の公証を設定済み
• 自動更新の仕組みを実装し、テスト済み
• 段階的ロールアウト戦略を定義済み
• セキュリティチェックリストを完了済み
• リリースノートを準備済み

詳細な設定例、コードサンプル、GitHub Actions ワークフローについては、references/patterns.md を参照してください。