Shopify のテーマ開発をチームで行う時の仕組み、試行錯誤

こんにちは、 Gaji-Labo 横田です。
前回、Eコマース用のプラットフォーム Shopify によるチームでのテーマ開発での課題を共有しました。
その解決策のひとつとして「Shopify のテーマ開発を GitHub Actions で効率化する」を石垣がまとめてくれましたが、その上でひとつひとつの課題をどうフォローしているか、まとめたいと思います。

GitHub でのコード管理に含められないページがある

管理画面の「ページ」で追加したページや、「法務関連 > 法的ページ」で作成するページ、「ブログ記事」で追加したページ、「設定 >ファイル」でアップする画像ファイルなど。また、管理画面から直接コード編集されると「いつ」「だれが」更新したか不明となり、コード管理から外れてしまう。

https://wp.gaji.jp/2021/05/13/7279/

Shopify の仕様により、テーマファイルではこれらのページやファイル、メニューを差分管理することができません。そこで自動バックアップできる有料アプリを導入することにしました。以下を試してみています。

• Rewind Backups
• Automatic Backups by Talon

Theme Kit のコマンドラインからデプロイしても、管理画面のテーマのタイムスタンプに反映されない

管理画面のテーマのタイムスタンプは、管理画面上で直接「保存する」ボタンを押した時の日時が反映されているようで、Theme Kit のコマンドラインからデプロイしても、タイムスタンプに反映されない。

https://wp.gaji.jp/2021/05/13/7279/

Shopify の仕様なので、運用上、タイムスタンプを確認項目とはしないルールとしました。

Gulp でのコンパイルを明示的な手順として何度かはさまないと、デグレが起こることがある

新規構築・運用の作業フローの手順書に、明示的に組み込みました。具体的には、

1. 作業時
2. プレビュー確認後

の2回、必ずコンパイルを走らせるようにしています。

複数の作業ブランチとプルリクエストを切り替えながら同時並行で進めることができない　

開発環境として development テーマがひとつしかない状態だと、複数の作業ブランチとプルリクエストを切り替えながら同時並行で進めることができない。

https://wp.gaji.jp/2021/05/13/7279/

作業ブランチごとに、ブランチ名と同じ名前のテーマを自動で都度生成することにしました。詳しくは「Shopify のテーマ開発を GitHub Actions で効率化する 」をご覧ください。

プルリクエストマージ後に、本番テーマにデプロイし忘れるというヒューマンエラーが発生しやすい

新規構築・運用の作業フローの手順書に、明示的に組み込むことでフォローしています。
また、プルリクエストマージ後に、開発テーマを自動で削除することが現時点では出来ない為、GitHub のプルリクエストに TODO メモとしてチェック項目を残しています。

theme get コマンドを使うと、ローカルのテーマ全体が本番環境に置き換えられてしまう

本番公開用テーマの差分取り込みに、theme get コマンドを使うと、ローカルのテーマ全体が本番環境に置き換えられてしまう。

https://wp.gaji.jp/2021/05/13/7279/

新規構築・運用の作業フローの手順書に、注意点として使用しない旨を明記しました。

本番デプロイ時に オプションを付けないデプロイタイミングを見計らう必要がある

基本的には本番デプロイ時に -n オプションを付けることで、ローカルに存在しないファイルでも本番環境から削除しないようにしているが、不要なファイルが本番環境にいつまでも残り、Git との差分として毎回表示されてしまうことがあるため、オプションを付けないデプロイタイミングを見計らう必要がある。

https://wp.gaji.jp/2021/05/13/7279/

本番公開前の新規構築フェーズでは、チーム内でタイミングを共有しながら、オプションを付けないデプロイを任意で実行しています。運用フェーズについては、まだ課題として残っています。

同時並行で複数人の作業が重なることがあるため、不具合やデグレが起きたり、設定が消えてしまうことがある。

運用フェーズでは特に、同時並行で複数人の作業が重なることがあるため、本番公開用テーマの差分取り込みを明示的な手順として何度かはさまないと、不具合やデグレが起きたり、設定が消えてしまうことがある。しかし、自分の作業を本番環境にデプロイする直前に本番公開用テーマを取り込んでしまうと、コンフリクトや、逆に自分の作業の消失が起こってしまう。

https://wp.gaji.jp/2021/05/13/7279/

作業ブランチごとに、ブランチ名と同じ名前のテーマを自動で都度生成することにしました。詳しくは「Shopify のテーマ開発を GitHub Actions で効率化する 」をご覧ください。
また、新規構築・運用の作業フローの手順書に、明示的に本番公開用テーマの取り込みを組み込みました。具体的には、

1. 作業ブランチを作成した直後（作業前）
2. プルリクエストがマージされ、main ブランチに移動した直後

の2回です。本番テーマの変更を取り込んだ後に、main ブランチの変更を取り込みます。

本番リリース後に GitHub のコード管理に含めるというフローが必要となることがある

運用スピードを重視して、本番公開用テーマの管理画面での編集やファイル追加を直接行い、リリース後に GitHub のコード管理に含めるというフローが必要となることがあり、手元の開発とコンフリクトやデグレが起こる可能性がある。

https://wp.gaji.jp/2021/05/13/7279/

運用スピードを重視するため GitHub で develop ブランチは作成せず、 main ブランチと 作業ごとの開発ブランチのみの構成としました。
その上で、GitHub Action の導入と、新規構築・運用の作業フロー手順書を細かくまとめ、チーム内で共有することでカバーしています。

まとめ

GitHub Action の導入や、新規構築・運用の作業フロー手順書のチーム内共有で課題を少しずつ解決する道筋が見えましたが、手動での作業テーマ削除やGulpでのコンパイル、本番公開用テーマの取り込みフローを CI に組み込んだり、自動化した仕組みに改善していけそうな点もまだまだ残っています。
今後もより安全、スピーディに開発を進められるよう、柔軟に仕組みづくりを改善していきたいです。

Shopifyでのサイト構築やテーマ開発に興味がある方、実践でのポイントを吸収したいと思っている方などにおすすめの内容です。