Jivaro が CMS がなくても動作し続ける静的 Web サイトを構築する方法

設計目標: ソースを一度作成すれば、完全なデプロイが可能 HTML

Jivaro は、各編集アイテムを構造化メタデータと本文のみの HTML フラグメントとして保存します。リポジトリ所有のノード スクリプトは、これらのソースを共有テンプレートと結合し、完全な静的ページを生成し、すべての依存インデックスを更新し、公開前に結果を検証します。

ブラウザは通常の HTML を受け取ります。記事を表示するために、CMS API、データベース クエリ、またはクライアント側のコンテンツ フェッチは必要ありません。

ソースモデル

content/resources/<slug>/
  article.json
  body.html

content/news/<year>/<slug>/
  article.json
  body.html

article.json は、タイトル、説明、日付、分類、ヒーロー、FAQ、ソース、関連リンク、アプリの関係、インデックス作成、および従来の URL を所有します。 body.html は H2 から始まり、グローバル ページ クロムは除外されます。

なぜ本体のみ HTML

新しい依存関係がゼロのシステムには、ブラウザとジェネレータがすでに理解している形式が必要です。 HTML フラグメントは、Markdown パーサーのインポートや部分パーサーの維持を回避します。その代償として、本文内に完全なドキュメント、H1、グローバル スタイル、スクリプト、またはジェネレーターが管理するセクションが存在しないという、厳密なオーサリング ルールが必要になります。

決定論的ジェネレーター

1. サイトのデータ、分類法、アプリ、ソフトウェア、コンテンツを読み込みます。
2. フィールド、日付、カテゴリ、ルート、画像、ソースを検証します。
3. 見出し ID を割り当て、TOC を生成します。
4. 記事またはニュースのレイアウトをレンダリングします。
5. FAQ、ソース、関連する読書、アプリ カード、広告を生成します。
6. ハブとカテゴリ ページを生成します。
7. サイトマップ、検索インデックス、フィード、リダイレクト、コンテンツ グラフ、監査を生成します。
8. 完全な出力を public/ に書き込みます。

ソースを変更せずに同じビルドを 2 回実行しても、差分は生成されません。

生成された HTML がコミットされる理由

• GitHub には、Cloudflare が提供する正確な Web サイトが含まれています。
• Cloudflare は公開フレームワークをインストールしません。
• 失敗したリモート ビルドではルートを消去できません。
• レビュー担当者は、最終的なメタデータと HTML を検査できます。
• ロールバックは Git を元に戻すことです。
• リポジトリ アーカイブは引き続きデプロイ可能です。

情報源は依然として信頼できるものです。生成されたファイルは手動で編集されることはありません。

共有テンプレートと段階的な移行

テンプレートは、ドキュメント シェル、ナビゲーション、メタデータ、構造化データ、記事レイアウト、TOC、FAQ、ソース、関連カード、およびフッターを所有します。静的ページ ノーマライザーは、共有アセット、スキップ リンク、画像サイズ、安全なリンク、見出しの修復、カタログの状態、および計画されたオファーの処理を古いページに適用します。

すべてのインデックスは同じグラフから得られます

品質管理は公開中です

npm run verify は、メタデータと廃止されたアセットをクリーンアップし、静的ページを構築、正規化し、ルート/アセット/メタデータ/スキーマ/フィード/リダイレクトをチェックし、カタログ レイアウトをテストします。公開出力の下書き、重複した ID、壊れた目次、古いファイル、競合するスクロール所有者、サイズが大きすぎる最適化された画像、誤った添付ファイルを拒否します。

Cloudflare はコンテンツ データベースではなくホストです

Cloudflare ページは、コミットされた public/ ディレクトリを公開します。関数は、承認されたリダイレクトとアフィリエイト ルートを処理します。ホストを移動するには、コンテンツ データベースを移行するのではなく、ヘッダーと関数を調整する必要があります。

このシステムで提供できないもの

• ビジュアルブラウザエディター。
• マルチユーザー編集権限。
• デフォルトでホストされたドラフト ワークフロー。
• データベースのクエリまたはパーソナライゼーション。
• 自動編集判断。

Jivaro は、携帯性、確定的な出力、直接制御のために最適化された狭いシステムを選択しました。

公開ワークフロー

1. ソースシェルを作成します。
2. メタデータと本文を書き込んで検証します。
3. ヒーローと最適化されたバリアントを追加します。
4. 構造化ソース、FAQ、および関係を追加します。
5. ドラフトを false に設定します。
6. npm を実行し、verify を実行します。
7. publish.ps1 を使用して、コミット、リベース、リビルド、プッシュを行います。
8. Cloudflare を待って、ライブ QC を実行します。

障害の回復とロールバック

生成、静的 QC、レイアウト QC、Git チェック、または確定的リビルドが失敗した場合、公開スクリプトはプッシュを拒否します。以前のパブリック ファイルは、検証済みのコミットによって置き換えられるまで Git に残ります。生成が間違っている場合、オペレーターはコミットを元に戻し、Cloudflare に以前に生成された出力を提供させることができます。

次に、ライブ QC は、正規ルート、代替ホスト リダイレクト、レガシー リダイレクト、およびビルド マーカーを要求します。これにより、リポジトリは正しいが、ホストが古いデプロイメントまたは異なるプラットフォームを提供しているという障害のクラスが捕捉されます。

Jivaro が CMS を採用する場合

CMS は、技術者以外の作成者が視覚的な編集、役割と権限、ワークフローの状態、ホストされたプレビュー、スケジュール設定、またはリポジトリのレビューを超える規模での構造化された再利用を必要とする場合に魅力的になります。移行の決定には、エクスポートの保証と静的フォールバックが含まれます。 CMS を避けることはイデオロギーではありません。それがこのチームとサイトの現在のトレードオフです。

よくある質問

関連書籍

出典と参考文献

• Cloudflare ページのドキュメントCloudflare · リファレンス
• GitHub アクション ドキュメントXXQPH0002QXZGitHub ドキュメント · リファレンス