新しいサイトを一つ立ち上げるたびに、記事を一本更新するだけなのに手元でビルドしてサーバーにアップロードして、という工程が地味な負担になっていました。今回、Eleventy(11ty)とSveltia CMSで新規サイトを構築する機会があり、最初からGitHub Actions経由の自動デプロイを組み込んでみたので、そのときの考え方と具体的な手順を書き残しておきます。
手作業のデプロイが負担になっていた理由
静的サイトは表示が速く管理もしやすい一方で、「原稿を直したら手元でビルドし、できあがったファイルをアップロードする」という一手間が必ず発生します。この一手間は、忙しい時ほど忘れがちです。ビルドし忘れたまま古い内容が公開され続けていたり、アップロード先を間違えたり。小さなミスですが、自分で気づくまで誰も教えてくれないところが厄介でした。記事を「書く」作業と「公開する」作業は、できるだけ切り離しておきたい。そう考えて、今回はサイトの土台を作る段階で「編集したら自動で公開される」仕組みを先に設計することにしました。
Eleventy＋Sveltia CMSを選んだ理由
Eleventyは、Markdownで書いた原稿を静的なHTMLに変換してくれるサイトジェネレーターです。サーバーもデータベースも要らないので、動作が軽く、セキュリティ面で気を使う箇所も少なくて済みます。ここにSveltia CMSを組み合わせると、ブラウザの管理画面から記事の追加・編集ができるようになります。裏側ではGitHubリポジトリに直接コミットが積まれていく仕組みなので、開発環境を用意しなくても、管理画面でタイトルと本文を入力して保存するだけで、原稿がリポジトリに反映される状態を作れます。
GitHub Actionsで「pushしたら自動で公開」を作る
ここまでで「原稿の変更がGitHubに届く」ところまでは自動化できました。残るは、その変更を実際のサイトに反映する部分です。ここでGitHub Actionsを使います。リポジトリの.github/workflows以下にワークフローファイルを一つ置き、mainブランチへのpushをトリガーにして、依存パッケージのインストールとEleventyのビルドコマンドを実行し、できあがった静的ファイルをそのままデプロイ先へ渡す、という流れを組みました。デプロイ用のトークンなどの秘密情報はGitHubのSecretsに登録しておくので、コードの中に鍵を書き込む必要もありません。これで、Sveltia CMSの管理画面で記事を保存した瞬間から、ビルドと公開までが人の手を離れて進むようになりました。
実際に動かしてみてわかったこと
仕組みを組んだ直後は、Actionsが実際にどう動いているか、実行結果のログを一度自分の目で確認しておくことが大事だと感じました。想定通りに動いていることさえ確認できれば、そのあとは記事を書くこと、CMSの管理画面を触ることだけに集中できます。デプロイという工程そのものを意識しなくてよくなったのは、思っていた以上に気が楽なことでした。地味な作業ほど、仕組みにしてしまえば頭から追い出せるのだと、あらためて実感した出来事です。
まとめ
こうした「手作業を仕組みに置き換える」考え方は、サイト運用に限った話ではないと思っています。日々の業務の中にも、気づかないうちに繰り返している手作業はたくさんあるはずです。動画制作の現場でもAI活用の支援でも、まず「どこが人の手を止めているのか」を一緒に洗い出すところから始めています。同じような手間に心当たりがあれば、ぜひ一度お話しできればうれしいです。ご相談はお問い合わせからお願いします。