GitHubを利用したPowerCMS Xのテーマ運用の実際

PowerCMS Xの開発、そしてウェブサイト構築・運用案件にも携わっている安倍です。イマドキのフロントエンドに興味があり、Next.jsを使用したブログ構築も経験したことがあります。今日はPowerCMS X利用者目線で記事を書きたいと思います。

ある案件でテーマを利用せず、開発環境で制作したビューを本番環境にコピーアンドペーストで適用していたのですが、誤りなく本番環境に適用しようにも確認がしづらかったり心理的負荷が大きかったりしました。そこで、Theme_GitHubプラグインを利用して本番環境に適用することでリリース作業を行えるようにしました。

Theme_GitHubプラグインの基本的な設定については、「テーマをGitHubで管理する | PowerCMS X」及びそのページからリンクされているページをご覧いただければと思います。

下準備

今回の案件では構築時に独自のテーマが適用された状態でした。もしまだテーマが何も適用されていない、もしくは標準テーマが適用されている状態の場合、ビューの一覧からリストアクション「テーマのエクスポート」を実行し、環境変数theme_pathsで指定したディレクトリに配置して、そのテーマを適用します。

その後、本番環境でビューの編集画面にあるベースネーム・ファイルへのリンクを漏れなく設定していきました。%t/news/index.tmplのようにディレクトリ名とファイル名をファイルへのリンクに設定すると、テーマエクスポート時に指定したディレクトリ・ファイル名でビューが出力されるので、ビューを判別しやすくなります。（設定しなかった場合はUUIDが利用されます。）

最後に、theme.jsonにリポジトリ情報を記述して本番環境に再度適用します。これでGitHubからPullするための設定ができるようになります。何も更新作業がないタイミングを見計らって開発環境にも同一のテーマを適用しました。

テーマ適用時に同一のビューであると判断される材料は？

本番環境にテーマを再適用すると不具合が起こらないか（具体的には同一のビューと判断されず、ビューの数が増えてしまうのでは？）と心配でした。実際には何も問題は起こらなかったのですが、実装を調べたところテーマ適用時には同一のビューであることを判断する材料として以下の項目が使われるので、重複しないように気を付けてください。

• 名前
• ベースネーム
• クラス
• UUID

全ての情報をAND条件で検索しておらずOR条件で検索しているので（ベースネームとクラスはAND条件）、名前を変更してもUUIDが同じであれば同じビューと判断されます。ないと思いますが、誤ってUUIDを重複させることがなければ大丈夫です。

運用

各自がローカルに開発環境を持ち、ローカル開発環境でビューを編集してコミット、リリース日にmainブランチにマージして本番環境に適用、とできれば良いのですが、PowerCMS Xのライセンスの問題、さらにクライアントにデータを入力してもらったり表示を確認してもらったりする必要があるため、なかなかそうはできないだろうというのが現状です。

では開発環境でビューを編集してコミットすれば？と思われますが、複数のチケットの更新作業をしているとビューには複数の作業内容が混ざっている可能性があって、単純にはコミットできないケースも予想されます。（TowerのようなGitクライアントだと編集した行を選択してそこだけコミットできるのですが…）

よって、現状では開発環境のビューを手元でマージしてGitHubにPushしています。（実装作業中はチケット毎にブランチを切って保存しておくのも良いかも。）Next.jsを触った経験も踏まえ、本番環境のブランチにマージするまでの工程で何かイノベーションを起こせないかとずっと考えているのですが、なかなか良いアイデアが浮かびません。

ビューを新規追加した場合

開発環境でビューの一覧からリストアクション「テーマのエクスポート」を実行します。そして、viewsの中にある新規追加したテンプレートファイルをリポジトリのviews内に配置します。そして、theme.json内の新規追加したビューに関する情報（下記のようなコード）をリポジトリのtheme.jsonにマージしてコミットします。

"000d9725-9d3a-479e-8467-b3cbae9c5b56": {
    "name": "記事一覧",
    "subject": "",
    "status": "2",
    "class": "Archive",
    "basename": "entry_list",
    "linked_file": "%t/news/entry_list.tmpl",
    "urlmappings": [
        {
            "name": "記事一覧",
            "model": "template",
            "mapping": "news\/index.html",
            "date_based": "",
            "publish_file": "1",
            "container": "entry",
            "container_scope": "1",
            "trigger_scope": "0"
        }
    ]
}

これを本番環境に適用すると、ビュー・URLマップが新しく追加されます。

ビューを更新した場合

開発環境のビューの内容をリポジトリのviews内にある該当ファイルに反映します。これをコミットして本番環境に適用するとビューが更新されます。更新前の状態はリビジョンに残ります。

ビューもしくはURLマップを削除した場合

リポジトリのviews内にある該当ファイルを削除します。さらにtheme.json内にある当該ビュー・URLマップの情報を削除してコミットします。

これを本番環境に適用するとビュー・URLマップが消えて欲しいのですが…、現状は消えません。theme.jsonを上からなぞって処理するだけだと削除したという情報が得られないからだと考えます。（1つ前のtheme.jsonと比較する必要があるということ。）これは製品の検討課題でしょうか。とりあえず手動で削除処理をしています。

細かい話や注意点

• Pullしたテーマはpowercmsx/support/themes/pull/[ワークスペースID]に格納されます
• テーマの適用時はtheme.jsonを上からなぞって処理・保存していくので、全てのビュー・URLマップの更新日時が変わります
• 本番環境に適用後は手動で再構築を行う必要があります
• 本番環境でビューが編集されている可能性があるので、ビューの更新日時もしくは「GitHubにコミット」ボタンを押して差分がないか確認した方が良いかもしれません（もしくは本番環境の管理画面デビューを編集しないというルールにする）

運用結果

• GitHubを利用することで事前に差分を分かりやすく可視化できました
• 過去にどのようなコードを反映したのかをGitHubで確認できるようになりました
• 本番環境反映にかかる所要時間の短縮、心理的負荷の大幅軽減ができました

おわりに

Theme_GitHubプラグインを利用した運用を、利用者目線でまとめてみました。環境や運用状況に合わせて適宜調整しながらお試し頂ければと思います。本番環境は誤りの無い確実な操作が求められるので、私はテーマ化して本当に楽になったなと感じます。あとは更新方法を関係者に確実に共有しておくことが大事だと考えています。

カテゴリー：技術情報

投稿者：安倍