2025年5月22日
これまで GitHub 経由でデプロイしていた mono.hyuki.com を、Netlify CLI によるローカルからの直接デプロイに移行した。これにより、ビルド後すぐに高速に公開できるようになり、ソースコード管理（GitHub）と公開（Netlify）を分離した柔軟な運用が可能になった。
-
GitHub との連携を Netlify の管理画面から解除
-
netlify loginとnetlify linkを実行し、CLI での連携設定を完了 -
公開ディレクトリ
public/をデプロイ対象とするためnetlify.tomlを作成：[build] publish = "public"
-
Makefileを以下のように修正し、ruby builder.rb --deployに一本化：auto-mono: @ ruby builder.rb --deploy -
builder.rb側に--deployオプションを追加し、更新があったときのみnetlify deployを実行するよう変更 -
cron.privateを一時停止して動作確認後、再起動して自動化運用を再開 -
実際に Mastodon への投稿→ビルド→CLIデプロイの流れが正しく動作することを確認
-
現在は RSS 更新が検出された際に全ページを削除して再構築しているため、不要なビルドが多く発生している
-
将来的には以下の対応を行う予定：
database.yamlに:DIR（タイムスタンプベースのディレクトリ名）を保存- RSS に含まれていない過去の投稿のみ削除する仕組みに変更
- 再構築対象の絞り込みによる処理の高速化
移行作業はスムーズに進行し、Netlify CLI を用いた自動デプロイ体制が整った。最小限の構成で堅実に動作し、今後のメンテナンス性や拡張性にも優れた構成となった。次の段階では更新対象の絞り込みやビルドの効率化に着手していく予定。
以下に、前回のレポートの続きとして「追記」版の report.md をまとめました。タイトルはご指定どおり「mono.hyuki.comをGitHub連携からNetlify CLIに切り替える作業（追記） by #ChatGPT」です。
2025年5月22日
前回のレポートにて、mono.hyuki.com を GitHub 連携から Netlify CLI による直接デプロイ方式へ切り替えた。その後、ビルド処理の無駄を省き、database.yaml の整備と最適化によって、全体の処理速度が大幅に改善された。本稿ではその後の具体的な作業を追記する。
- 各エントリに対応する
public/YYYYMMDDHHMMSS/形式のディレクトリ名（id14）を、database.yamlの:DIRフィールドとして保存 build_with_urlにてページ作成時に:DIRを明示的に登録するよう変更
DATABASE[id][:DIR]を参照し、public/:DIR/index.htmlが既に存在する場合はwgetをスキップ- 無駄な再構築と通信を回避し、ビルド処理が大幅に高速化
-
add_dir_to_database.rb各エントリの URL からwgetによってog:published_timeを取得し、:DIRを生成・補完 -
clean_database_from_public.rbpublic/以下に対応するページが存在しないエントリをdatabase.yamlから削除 -
fix_title.rb各index.html内の<title>タグを読み取り、database.yamlの:TITLEを正しく更新
build_with_urlにて:hyuki:を含まない投稿はスキップ対象とし、該当のDATABASE[id]を削除
- 不要な投稿の削除、無駄な再構築の抑制、メタデータの正確化により、ビルド速度は爆速化
public/ディレクトリとdatabase.yamlの整合性が保たれたことで、今後の自動処理・管理もより安全に- 将来的には
--dry-runや--forceオプションの導入により、柔軟な運用を予定
もともと堅牢だった構成をさらに丁寧に見直し、実際の運用を前提としたツール群により、mono.hyuki.com のビルドとデプロイは大幅に改善された。GitHub 連携から解放され、より制御性の高い、軽快で堅実なシステムが完成しつつある。