WordPress

Netlify CMS(Hugo)のテーマをGitの使い方を覚えながらカスタマイズしてデプロイしてみよう

投稿日:2018-10-25 更新日:

Netlify CMS(Hugo)でMarkdownで記述可能な無料ブログを構築する(構築編) – OTTAN.XYZで、Netlify上に静的サイトを構築する方法をご紹介しました。今回は、Hugo(Go言語の静的サイトジェネレータ)のスターターキットで構築したテーマをカスタマイズして、GitHub上のソースコードの修正、Netlifyによる自動デプロイ、デプロイ結果のSlackへの通知までを行います。

なお、今回はデプロイすることが目的であるため、IDE(統合開発環境)は使用しませんが、通常はVisual Studio Codeなどを使用した方が効率的でしょう。

Netlify CMSのテーマをカスタマイズしてデプロイする

冒頭の記事でも触れましたが、Netlify CMSの基本的な流れとしては、

  1. GitHubからソースコードを取得
  2. テーマのソースコードをカスタマイズ
  3. カスタマイズ後のテーマをGitHubにプッシュ
  4. Netlifyによる自動デプロイ

となります。デプロイに関しては、Netlify側で自動実行されるため(デプロイのオプションをカスタマイズすることも可能)、特に気にする必要はありませんが、GitHubからソースコードを取得し、最終的にGitHubへプッシュするまでは利用者側の責任となりますので、多少なりともGitの使い方を習得しておく必要があります。

今回は、基本的なGitの使い方も含めて一連の流れを見ていきたいと思います。いきなりVisual Studio Codeなどの補助ツールを使用しても良いのですが、まずは基本的な流れを押さえておくと理解がより深まるかと思います。

GitHubからソースコードの取得

では、まずソースコードを取得するための作業ディレクトリを作成しましょう。今回はホームディレクトリの下にworkディレクトリを作成し進めることとします。なお、以下の作業は全てMacで実施していますが、流れはWindowsでも同様です(別途、Gitコマンドの導入は必要です)

mkdir ~/work
cd ~/work

ターミナルを開いて上記のコマンドを実行し、作業ディレクトリを作成します。Finderから実行しても構いません。このような作業からターミナルでの作業に慣れておくと、「黒い画面」に対する違和感をなくしていけるでしょう。

続いて、GitHubのリポジトリからソースコードを取得します。

git clone https://github.com/ottanxyz/one-click-hugo-cms
cd one-click-hugo-cms

gitの「clone」コマンドを使用することで、ローカルのリポジトリにソースコードを取得することができます。リポジトリ名のディレクトリが作成されるため、cdコマンドで作業ディレクトリを移動します。

テーマのカスタマイズ

GitHubは、gitベースの分散型バージョン管理システムです。新規バージョンのリリースに向けて作業を実施する人、現行バージョンのバグフィックスを行う人など、複数人で作業を実施するのに向いています。通常、このように複数人で作業を実施する場合は、「ブランチ」と呼ばれる作業ディレクトリの複製を作成して作業を進めます。「ブランチ」を作成しないと、バグフィックスチームによって修正された現行バージョンのバグが、新規バージョン開発チームのソースコードに取り込まれないまま、新規バージョンでまたバグ修正を行うという悪循環に陥ってしまいます。

そのため、例えば「bugfix」「feature」と呼ばれるブランチを各々のチームがオリジナルのブランチ(master)とは別に作成し、それぞれのブランチで作業した上で、最終的に全てのブランチのソースコードレビューを得た上で、オリジナルのブランチにマージするということが必要です。この「マージ」によって、バグフィックスチームによる修正箇所と、新規機能開発チームによって作成された箇所を、並行して開発しながら安全に組み込むことができるというわけです。

初めてgitを使用する場合は戸惑うことが多いかもしれませんが、まずは、このような基本的な事項さえ押さえておけば大丈夫です。その他にも「タグ」などの概念もよく利用されますが、今回はひとまずブランチを作成してみましょう。

git branch feature
git checkout feature

「feature」というブランチが作成され、checkoutコマンドによりブランチを切り替えました。これでオリジナルの「master」ブランチに影響を与えることなくソースコードの修正を行うことができるようになります。

今回は、Gitによる練習を兼ねて、siteディレクトリ配下にある、config.tomlファイルを編集します。

vim site/config.toml

configファイルに記載されているタイトルを、デフォルトの「Homepage」から「Sample」に変更します。ソースコード上から「title」という値を読み取った際に「Sample」に変更されるようになります。

続いて、変更したファイルを現在のリポジトリに反映します。現在編集したファイルはローカルで反映しただけですので、リモートのリポジトリであるGitHubには反映されていません。まず、変更する行為を「コミット」と呼びます。変更する前に、変更した箇所の差分を表示するためには以下のコマンドを実行します。

git diff

以下の図のように変更点のみ表示されます。

さて、修正箇所が確認できたらソースコードをコミットしましょう。コミットするためには、以下のコマンドを入力します。

git add .
git commit -m "modify config.toml

addコマンドは、現在の作業ディレクトリ配下のファイルをGitの管理対象に追加することを意味します。具体的にファイル名を指定したり、今回のようにディレクトリ全体を指定したり、ワイルドカード指定(拡張子指定する場合など)することもできます。余分なものを誤ってコミットしてしまわないように、事前にaddコマンドで管理対象に追加(ステージング)する必要があります。追加したら、commitコマンドでリポジトリに変更を加えます。-mオプションでは、そのコミット内容に対する変更点を具体的に明記します。今回は英語で記述していますが、日本語も使用できます。

変更を元に戻したいときは?

ファイルを誤って修正してしまった場合など、元のバージョンに戻したいときがありますが、その場合は下記のコマンドを使用します。

git checkout .

.は、現在のブランチを表しています。そして、checkoutコマンドは、前述のブランチを変更するためのコマンドでした。これで現在のブランチの状態(変更される前のブランチ)に戻ります。

commitコマンドにより、ローカルのリポジトリが最新化されました。なお、同コマンド実行時に下記の図のような内容が表示されたかもしれません。

Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

これは、gitコマンドによるソースコードをコミットした人の情報が、gitのグローバル変数に登録されていないためです。初回のみ、以下のコマンドを実行し、ユーザー情報を登録しておきましょう。

git config --global user.name <User Name>
git config --global user.email <Email>

GitHubへのソースコードのプッシュ

では、今度はリモートのリポジトリ、つまりGitHubに更新内容を反映してみましょう。GitHubには、Pull Request(プルリク)と呼ばれる機能がありますが、今回は使用しません。リモートのリポジトリに登録するためにはpushコマンドを使用します。

git push origin feature

これで、リモートリポジトリへの登録が完了しました。「feature」ブランチの修正が完了したため、いよいよオリジナルとなる「master」ブランチへ修正内容を反映しましょう(この作業を「マージ」と言います)。

git checkout master
git merge feature

一度、ブランチ作成元となる「master」ブランチに切り替えた後(checkout)、「merge」コマンドにより修正したブランチの名前を指定してマージを行います。

Updating 73bd5e8..16409c0
Fast-forward
 site/config.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

今回修正した「config.toml」が自動的に「add」されていることがわかります。最後に、「master」ブランチの内容を確定させます。

git push

以上で、GitHub上のオリジナルのソースコードの修正が完了しました。流れを簡単にまとめると以下の通りとなります。

  1. 「branch」コマンドで新規ブランチを作成する
  2. 「checkout」コマンドで作成したブランチにローカルリポジトリを切り替える
  3. ソースコードを修正する
  4. 「add」コマンドでコミット対象とするファイルを確定する
  5. 「commit」コマンドでローカルリポジトリの修正内容を確定する
  6. 「push」コマンドでリモートリポジトリ(GitHub)のブランチの修正内容を確定する
  7. 「merge」コマンドでオリジナルのブランチと新規作成したブランチの内容をローカルリポジトリ上でマージする
  8. マージした内容に問題がなければ「push」コマンドでリモートリポジトリ(GitHub )のオリジナルの修正内容を確定する

gitの使い方に慣れていないと、初めのうちは戸惑うかもしれません。しかし、一つ一つの内容を理解すれば、各コマンドで実行している内容はそれほど難しいものではありません。まずは、一つ一つ今実行しているコマンドの内容を理解しながら進めてみてください。もちろん、ブランチを作成する必要がない場合は、「add」「commit」「push」で終わります。

Netlifyによる自動デプロイ

ここは特に説明する必要はありません。通常、デプロイは利用者自身が行う必要がありますが、Netlifyはデプロイを自動で行ってくれるため、利用者が意識する必要はありません。あくまでソースコードの修正だけです。

デプロイ結果のSlackへの通知

デプロイ結果は、Netlifyの管理ページから確認することもできますが、毎回Netlifyの管理ページを確認するのは手間がかかります。また、デプロイが成功していれば問題ありませんが、万が一デプロイが失敗してしまった場合、修正内容を反映することができません。今回は、デプロイが成功したらSlackに通知するようSlackのWebhookを利用します。

Slackでチャンネルを作成します。デフォルトの「general」チャンネルでも問題ありませんが、通知を分割するために個別のチャンネルを作成することをお勧めします。チャンネルを作成したら、着信 Web フックにアクセスします。

作成したチャンネルを選択して「着信Webフックインテグレーションの追加」をクリックします(少しおかしな日本語訳な気もしますが)。

「Webhook URL」が生成されるのでコピーしておきます。URLをコピーしたら、Netlifyにサインインしてダッシュボードに移動します。

サイドメニューから「Build & Deploy」を選択し、最下部にスクロールします。「Deploy notifications」という項目がありますので、「Add notification」をクリックします。「Slack integrations」というメニューがあるため、こちらをクリックします。

通知のタイミングは、「デプロイ開始時」(Deploy started)、「デプロイ成功時」(Deploy succeeded)、「デプロイ失敗時」(Deploy failed)等から選択可能です。今回は「デプロイ成功時」を選択します。また、「Slack Incoming Webhook URL」に先ほどコピーしたURLをペーストします。

以降は、デプロイが成功したタイミングでコミットメッセージとともに、Slackに通知されるようになります。必要に応じて、他のタイミングのメッセージを追加しておくと、デプロイを追跡できるようになるかと思います。

-WordPress
-, , , ,

執筆者: