EX FOUNDRYのリリース運用：検証から公開までをGitHub Actionsで行う

公開の入口を一つにする

EX FOUNDRYの変更は、Pull Requestで確認してから main へマージします。記事本文だけの変更でも、記事一覧、検索用メタデータ、sitemap、構造化データ、トップページの表示が変わることがあるため、コード変更と同じ公開経路で扱っています。CIではフォーマットとLint、型チェック、テスト、ビルドを順に実行し、すべて成功した成果物だけをGitHub Pagesへ公開します。

Pull Request
  ↓ pnpm verify
mainへマージ
  ↓ deploy workflow
GitHub Pages

記事本文、sitemap、robots.txt、JSON-LDはビルド時に同じデータから生成されます。本文だけを変更したつもりでも公開URLやメタデータに影響することがあるため、静的出力を確認しています。特に、front matterのパス、日付、記事分類、対象プロダクトが正しいか、記事詳細のcanonical URLとsitemapのURLが一致しているかを確認します。

公開後は、トップページ、記事一覧、記事詳細、アプリ一覧、編集方針、問い合わせ、プライバシーの導線を確認します。記事のHTMLが表示されることだけでなく、外部プロダクトのリンクが正しいドメインへ向いているか、スマートフォンのナビゲーションが読めるか、404ページから記事一覧へ戻れるかも確認対象です。

Pull Requestで確認する項目

コンテンツだけを変更したPull Requestでは、Markdownの見出しが目次へ反映されること、front matterの日付とパスが正しいこと、カバー画像が存在すること、外部リンクのURLと説明が一致することを確認します。記事分類や対象プロダクトを変更した場合は、記事一覧の絞り込み、カードの表示、記事詳細のラベル、構造化データの articleSection と about が同じ値になっているかも確認します。

サイトコードを変更したPull Requestでは、既存記事を一つ、長い表を含む記事を一つ、外部プロダクトへのリンクを含む記事を一つ選び、詳細ページのレイアウトを確認します。静的HTMLとブラウザのhydration後で見出しや本文が二重に表示されないこと、JavaScriptが無効でも最低限の本文とナビゲーションを読めること、記事本文のHTMLが初期JavaScriptへ無制限に埋め込まれていないことを検証します。

プロダクトのリリース情報

プロダクト側の機能追加は、それぞれのリポジトリでテストとデプロイを行います。EX FOUNDRYには、利用者に影響する変更、公開URL、使い方、構成上の判断をリリース記事としてまとめています。プロダクト本体のPull Requestと、EX FOUNDRYの記事更新は同じ変更であっても別の検証対象として扱い、本文に書いた機能が本番ページで確認できる状態になってから公開します。

リリース記事では「何が変わったか」だけでなく、「誰に影響するか」「どのURLで確認できるか」「既存の使い方が変わるか」「入力や保存の扱いが変わるか」「既知の制約は何か」を説明します。追加機能が試験的な場合は、完成済みの仕様のように書くのではなく、対象範囲と今後の変更可能性を示すようにします。

プロダクト側のリリースとEX FOUNDRY側の記事公開の順番にも注意しています。まだ本番で利用できない機能を先に公式記事として公開してしまうと、記事のリンクを開いた利用者が説明どおりの画面を見られません。反対に、機能を公開したあとに説明記事がない状態が長く続くと、利用者が使い方や入力データの扱いを確認できなくなります。実装、プロダクトの公開、公式記事の更新は、一つの変更記録として追跡します。

記事へ数値や性能の説明を追加する場合は、測定条件を残しておきます。端末、ブラウザ、データ量、取得時点、対象URLのない数値は、環境が変わったときに再現できません。確認できない利用者数、速度、対応範囲を記事の文量を増やすために推測で補うことはせず、実際に検証できる機能と制約だけを追加します。

記録を残す

サイトの構造を変更した場合は、コードだけでなくADRへ理由を記録します。記事の内容に誤りが見つかった場合はお問い合わせから受け付け、必要に応じて記事を修正します。

この運用により、プロダクトの画面と説明がずれたまま残る期間を短くし、更新の根拠を追える状態を保っています。更新を急ぐあまり、確認できていない機能や測定値を記事へ追加しないことも重要です。記事を長くする場合も、実装や一次資料で確認できる具体的な情報を増やし、一般論の繰り返しで埋めないようにします。

デプロイ後に誤りを見つけた場合は、まず影響範囲を切り分けます。リンクだけが誤っているなら記事を修正し、本文の仕様が現状と違うならプロダクト本体の画面とドキュメントを確認してから更新します。公開URLや記事パスを変更した場合は、sitemap、canonical、サイト内リンク、外部からの参照を確認します。修正内容が利用者の判断に影響する場合は、単なる誤字修正として扱わず、更新日と修正内容を記録します。

静的サイトのデプロイでは、GitHub Actionsが成功しただけで利用者が新しい状態を見られるとは限りません。Pagesへの公開、CDNのキャッシュ、ブラウザのキャッシュ、外部クローラーの取得は分けて考える必要があります。公開後の確認では、代表URLをHTTPで取得し、タイトル、description、本文、ads.txt、sitemapを確認します。表示が古い場合は、デプロイログと公開URLのレスポンスを比較してから再度判断します。