こんにちは。
ディベロッパーの石山です。

昨年より国産のheadlessCMSであるmicroCMSがサービスを開始したことを皮切りに、国内でも静的CMSの勢いが増してきました。
入稿画面に国産のサービスが利用できるのはクライアントワークにおける使用のハードルが低くなるため助かりますね。

私も社内の制作を通して試す機会を得たので、クライアントワークへと用いる前に実装にあたっての反省点などを備忘録として残したいと思います。

使用ツール・構成

使用ツールと構成は以下の通りです。

• CMS：microCMS
• CI/CD：circleCI
• hosting：Amazon S3

開発環境についてですが、microCMS公式のブログ内にて紹介されていました以下の内容で「確かに…!!」と関心し、今回はejs+gulp+webpackの環境を用いてみました。

Gulp + EJS + microCMSでJamstackな構成を実現する https://microcms.io/blog/gulp-ejs-microcms/

現在はvueやreactを用いたフレームワークが全盛かと思いますが、ejsやpug等のテンプレートエンジンとwebpack+gulpを用いての開発を行っている方も多いかと思いますので、そういった方々への導入の参考にもなりますと幸いです。

ちなみに上記の記事内でも使用されているNetlifyは静的サイトのホスティングにあたって文句無しの機能を揃えているのですが、惜しくも国内のCDNサーバーを用いるにはエンタープライズプランが必要のため、速度がネックとなり今回は使用を見送り、CI/CDはcircleCI、ホスティングはAmazon S3としました。

更新のフロー

更新からデプロイまでの手順は単純で、大枠では以下のようになります。

1. microCMSにて入稿し、webhook通知を送る
2. webhookによりAPIを呼び出し、circleCIでbuildタスクを実行
3. 出力されたディレクトリをAmazon S3へとdeploy

今回は主にそれぞれのサービスの連携についてのお話ができればと思います。
実装に関しては、先ほど紹介をしましたmicroCMSの公式の記事など、ドキュメントが多数ありますので今回は割愛いたします。

-準備物-

• githubまたはbitbucketのリポジトリ
• microCMSアカウント
• circleCIアカウント
• ホスティングサーバー(今回はAmazon S3)
• タスクを記述した.yml

それでは連携の作業を始めたいと思います。

01.microCMSにて入稿し、webhook通知を送る

microCMSではデータ入稿を行った際など、任意のタイミングでチャットツールやCI/CDへのwebhookを送ることができます。

一覧を見て頂くと分かる通り、公式としてはcircleCIとの連携には対応していません。(2020.07.01時点)
しかし、ありがたいことにカスタム通知からあらゆるサービスとの連携が可能となっていますので、今回はcircleCI API v1.1を使用してbuildジョブをトリガーしてみます。

02.webhookによりAPIを呼び出し、circleCIでbuildタスクを実行

カスタム通知を選択したら早速、以下のフィールドに入力していきましょう。

入力する値の雛形はこちらになります。
以下の《hoge》をそれぞれの内容に合わせて置き換えてください。

・vsc-type
バージョン管理システムの名称、’github’または’bitbucket’

・org
リポジトリを管理しているプロジェクト名

・repo
リポジトリ名

・branch
buildタスクを実行するブランチ名
.ymlの内容にもよりますが、デプロイまで行うのであれば’master’で良いかと思います。

・user-token
circleCIにて発行するPersonal API Tokensになります。
発行の際は以下をご覧ください。
https://circleci.com/docs/ja/2.0/managing-api-tokens/

置き換えた内容をフィールドに入力し、直下のセレクトボックスから通知のタイミングを設定して完了です。
通知は頻度が多過ぎるとbuild時間を浪費することになりますので気を付けてください。

なお、今回使用したAPIについてはcircleCIの公式ドキュメントを参考にしました。
ドキュメントには他にもご覧になると面白いかと思います。

API を使用したジョブのトリガー
https://circleci.com/docs/ja/2.0/api-job-trigger/

CircleCI API ドキュメント
https://circleci.com/docs/api/v1-reference/

03 - 1.出力されたディレクトリをAmazon S3へとdeploy

ここまで来るともう巨人の肩の上。世に散りばめられたTips記事や公式のドキュメントを見ながら簡単に進めることができます。

circleCIにはOrbsという設定要素をまとめたパッケージが存在しているため、簡潔な.ymlの記述のみでAWSへのdeployが可能になっています。初心者にも安心ですね。

Using the AWS S3 Orb
https://circleci.com/docs/2.0/deployment-examples/#using-the-aws-s3-orb

しかし、Orbsの使用はcircleCI 2.1からの機能。その手軽さに甘えてしまったのが失敗の始まりでした…..

03 - 2.バージョンごとの制約に踊らされる

そもそもドキュメントをしっかり読んでおけばこんなことにはならなかったのですが、まず結論から述べるとcircleCI API v1.1ではvirsion2.1で.ymlに記述されたジョブをトリガーすることはできません。そして、Orbsを使用できるのはvirsion2.1からです。
勿論そのバージョンの壁を越えてbuildタスクが起動することは無く、私はvirsion2.1による記述でdeployまで確認できていた.ymlの記述を疑いもせず、全く反応を示さないPipelineを眺めながらwebhookのPOSTの内容がおかしいのか…と意味も無くドキュメントを彷徨い続けてしまいました。大反省。

こうして半日を費やし、改めてversion2.0での書き直しに至る始末。
.ymlの内容を改めたことでジョブのトリガーとデプロイが確認でき、無事に入稿からデプロイまでの自動化が完成しました。

version2.0を用いたデプロイに関する記述については公式では以下の内容が参考になります。

Deploy to AWS S3 with 2.0 Config
https://circleci.com/docs/2.0/deployment-examples/#deploy-to-aws-s3-with-20-config

04.まとめ

複数サービスを跨いだ連携を構成する場合、バージョンごとの互換性の事前確認は細かく行いましょう。(します)

もう一点、microCMSとcircleCIの連携についてもAPIのドキュメントに辿り着くまで時間を弄してしまったのですが、Twitterで悩んでいる旨をツイートするとすぐにメンバーの方が参考になりそうなリンクを送って下さり、噂通りの親切さに感動でした。ありがとうございます。

使ってみた所感

実際に構築してみた感想をまとめる前に、改めて静的CMSの構築にあたって使用したサービスアカウントを振り返ります。

• microCMS
• bitbucketまたはgithub
• circleCI(bitbucketまたはgithubとの連携)
• Amazon S3

こう見るとやはり多い。というのが正直な感想ですね。

サービスをまたぐことになるため社内で完結する開発の場合は問題無いのですが、私たちのようなwebサイトの受託開発の現場ではクライアントにアカウント登録の依頼が発生するのは一つ一つがハードルになります。そのため、実案件での使用の際は密なやり取りや説明が必要になるかと思います。

また、今回は使用を見送ったNetlifyですが、CI/CDとホスティングの役割を一括で担ってくれるというのはクライアントの運用を簡潔にするという点においても良いサービスかと思います。
その分速度について厳しい意見が出てしまうのがとても惜しいですね…エンタープライズプランなら日本のサーバーが使えるみたいですが、料金については未知数です。

最後にmicroCMSの管理画面ですが、本当に使いやすかったです。
よほど複雑な内容でなければフリープランでの範囲内でも簡単に管理画面の作成が可能で、社内メンバーへの操作方法の共有もスムーズでした。

以上、最後は主に難点についてのお話になってしまいましたが、やはり動的CMSと比較すると様々な観点で恩恵を受けられるのは事実です。

使用にあたっては上手く要件や運用フローを見定める必要がありますが、クライアントにも実装者にもメリットは大きいため、これから利用できる幅が広がればと思います。
phpのバージョンアップ等に怯えなくても良い世界、輝かしいですね….。

それでは。