新しく占いをテーマにしたメディアサイトを立ち上げることになり、今回はEleventyとSveltia CMSという組み合わせで作ってみました。作りながらずっと考えていたのは、「更新のたびに手が止まる仕組みにはしたくない」ということです。今回はその設計をどう組んだか、具体的な手順とあわせて振り返ってみます。
なぜEleventy+Sveltia CMSを選んだのか
Eleventyは、書いた内容をシンプルなHTMLとして書き出してくれる静的サイトジェネレーターです。サーバー側でプログラムを常時動かす必要がなく、生成されたファイルをそのまま置くだけで表示できるので、運用の負担が軽いのが気に入っています。そこにSveltia CMSを組み合わせました。Sveltia CMSは、記事や画像の変更をそのままGitのリポジトリにコミットしてくれるヘッドレスCMSで、管理画面から記事を書けば、裏側では自動的にファイルの追加・更新としてGit履歴に残っていきます。エンジニアでなくても記事を更新できる画面を用意しつつ、実体はすべてGitで管理できるという点が、今回の仕組み作りの土台になりました。
手作業がどこに残るかを先に洗い出した
CMSで記事を編集してGitに変更が入っても、それだけではサイトは更新されません。Eleventyでビルドして、出力されたファイルを公開先にアップロードする工程が別に必要になります。ここを毎回自分の手でやることになると、結局「記事を書く→ターミナルを開いてビルドする→アップロードする」という手順が残ってしまい、CMSを入れた意味が半分になってしまいます。なので最初の設計段階で、「Gitに変更が入った瞬間から先は、すべて自動で終わらせる」ことを目標に決めました。
GitHub Actionsで組んだ具体的な流れ
実際に組んだのは、リポジトリのmainブランチに変更がpushされたタイミングで動くGitHub Actionsのワークフローです。CMS経由のコミットも、自分が直接編集したコミットも、mainに入った時点で同じトリガーとして扱われます。ワークフローの中身は大きく分けて、依存パッケージのインストール、Eleventyによるビルド、そしてビルド済みファイルをCloudflare Pagesへ公開するデプロイという3段階です。この日は配色を既存メディアの雰囲気に合わせて調整するコミットや、バナー用の写真素材を追加するコミットと並行して、このデプロイ用ワークフローを追加するコミットも入れました。1つのコミットに全部を詰め込まず、目的ごとに分けて積んでおくと、あとから見返したときにどの変更が何のためだったか分かりやすいのです。
組んだあとに実際に確認したこと
仕組みを組んだだけで安心して終わりにはしませんでした。ワークフローを追加したコミットをpushしたあと、GitHub Actionsの実行ログを開いて、ビルドとデプロイが実際に最後まで通っているかを確認しています。設定ファイルの見た目上は正しく書けていても、権限の設定漏れやビルドコマンドの微妙な違いで途中で止まっていることは珍しくありません。一度ログを最後まで緑色で通しておけば、次からは記事を書いてCMSで保存するだけで、あとは何もしなくてもサイトが更新される状態になります。この「最初の1回だけ手間をかけて、そのあとは手放す」という順番が、結局いちばん近道だったと感じています。
今回のように、繰り返し発生する手作業を仕組みの側に任せてしまう考え方は、動画制作の現場でも、日々の業務でAIを使ったやり方を考えるときでも、根っこは同じだと感じています。「今、手でやっていることの、どこまでを仕組みに任せられるか」を一緒に整理するお手伝いもしていますので、気になる方はご相談はお問い合わせからどうぞ。