こんにちは！今日は、Backstageの導入を検討されている方が最初に直面する岐路、つまり「どのようにプロジェクトを開始するか？」について深く掘り下げていきます。🚀
Backstageは単にダウンロードしてインストールするソフトウェアではなく、皆さんの組織に合わせて構築するフレームワークです。この時、npx @backstage/create-appを使用する方法と、メインリポジトリをForkする方法のどちらを選択するかが、今後の運用を決定づけます。💡
🏗️ Backstageを始める：二つの道の正体
1. @backstage/create-app (推奨方式) ✨
この方式はReactのcreate-react-appに似ています。コマンドを実行すると、Backstageフレームワークを基盤とした新しい独立したインスタンスが生成されます。
2. BackstageリポジトリのFork (開発者方式) 🍴
GitHubの公式Backstageリポジトリを自分のアカウントに複製（Fork）し、その中で直接修正を行う方式です。
🌟 何が違うの？詳細比較分析
1. プロジェクトの目的と構造 📂
- create-app: 皆さんは「ユーザー」になります。生成されたコードは最小限の設定ファイルとカスタマイズ可能な部分のみを含み、核となるロジックは@backstage/で始まるライブラリパッケージ形式で管理されます。
- Fork: 皆さんはBackstageの「コントリビューター」のような環境に置かれます。数千のファイルを含む全体のソースコードをすべて持ち、フレームワーク自体を修正する目的が強いです。
2. アップデートとメンテナンス (最大の違い！) 🔄
- create-app: `backstage-cli versions:bump`コマンド一つで最新バージョンへのアップデートが可能です。依存パッケージのバージョンを上げるだけで済むため、非常にクリーンです。
- Fork: 公式リポジトリに数千のコミットが上がるたびに、皆さんのフォークされたコードとのMerge Conflict（衝突）を解決しなければなりません。アップデートが地獄になる可能性があります。🌋
3. ビルド速度と軽さ ⚡
- create-app: 必要なパッケージのみを取り込むため、ビルドが速く、プロジェクトフォルダが比較的軽いです。
- Fork: 全体のモノレポをビルドする必要があるため、初期設定とビルド時間がはるかに長くなります。
🤔 どのような状況で何を選択すべきか？
| 選択基準 | @backstage/create-app 推奨 | Fork 推奨 |
|---|---|---|
| 一般的な企業導入 | ✅ 無条件に推奨 | ❌ 非推奨 |
| プラグイン追加および設定 | ✅ 非常に簡単 | ⚠️ 複雑 |
| Backstageコアへの貢献 | ❌ 不可 | ✅ 必須 |
| 自分だけのフレームワーク開発 | ❌ 不適切 | ✅ 適切 |
💡 なぜほとんどの人がcreate-appを使うべきなのか？
ほとんどの企業は、Backstageという「ツール」を使って開発者ポータルを構築することが目的であり、Backstageという「製品」自体を根本的に変更することが目的ではないからです。create-appで始めても、必要なすべてのカスタマイズ（UI変更、プラグイン追加、API連携など）が完璧に可能です。🛠️
🛠️ create-appで始める短いガイド
この方式が勝者であることが分かったので、どのように始めるか少し見てみましょうか？
- コマンド実行: ターミナルで以下を入力します。
- Bash
npx @backstage/create-app@latest- 名前設定: アプリケーション名を決めます（例: my-portal）。
- データベース選択: SQLite（テスト用）またはPostgreSQL（運用用）を選択します。
- 実行: 生成されたフォルダに移動し、`yarn dev`と入力すれば完了です！🎊
🏁 結論：「ツールを使え、ツールと戦うな！」
BackstageをForkすることは、車を運転したいのに、自動車工場のすべての設計図と組み立てラインを丸ごとコピーしてくるようなものです。単に運転（開発者ポータルの運用）が目的なら、@backstage/create-appという鍵を受け取ってエンジンをかけるのが賢明です。🏎️
皆さんのエネルギーは、コードの衝突解決ではなく、開発者体験（DevEx）を改善するプラグイン開発に注ぎ込んでください！
コメントを残す