Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

弊社Wordpressサイトのバージョン管理・デプロイの変遷

※この記事は、Speee Advent Calendar 4日目の記事です。

昨日の記事はこちら

はじめに

こんにちは、Speee開発の石原です。

今回は、弊社のWordpressサイトのバージョン管理・デプロイの変遷についてお話させていただきます。 バージョン管理すらされていなかったWordpressサイトが、Githubレポジトリの下に管理され、安全に更新・デプロイの可能な状態になるまでのお話です。

私が最初にWordpressを知ったのはいつの頃だったでしょうか。まだ学生だった頃、バイト先のWEBデザイン会社でのことだと思います。当時はMovable Typeが全盛の頃で、CMS/オープンソースなんて言葉を知らない私は、「わーどぷれすっていう無償のブログが出てきたよ」と耳にし、「無料じゃん!最強じゃん!」っとなんだかウキウキしていたのを覚えています。それからはご存知の通り。あっという間にMovable Typeを蹴落としCMSのシェアNo.1になっていきました。

そのお手軽さが許せない

Wordpressの特徴といえば、プラグインやテーマが充実していて、ブログからショッピングサイト等まであっという間に作れてしまうお手軽さではないでしょうか。各ホスティングサービスでも簡単にインストールできるのが当たり前。書籍やネットの情報も充実しているし、テーマのことをちょっと勉強すれば、オリジナルデザインのサイトが作れてしまいます。

デザイナーさんやWEB開発未経験の方が、とりあえずWordpressを使ってWEBサイトを立ち上げるなんて事も、よくあるのではないでしょうか。「ちょっとホームページ作ってよ」なんて軽く依頼されて、格安のホスティングサイトを契約してWordpress環境の作成ボタンをポチッと押して運用開始です。

でも運用を始めてみると、Wordpressが提供するのは良い『お手軽』さばかりではないと気づくはずです。Wordpressには更新作業がつきものです。バグ修正にセキュリティパッチ。更新を怠るとあっという間にバグだらけの危険なサイトに『お手軽』に変貌してしまいます。しかもプラグインやテーマは、組合わせやバージョンの差異によって『お手軽』にエラーが出てしまいます。

サイトの運営を複数人で行う場合は更に大変です。気づいたらよくわからないプラグインが『お手軽』に入れられていたり、設定が『お手軽』に書き換えられていたり。

お手軽が故に、色々な問題にぶつかってしまいます。私もご多分にもれず、それらの問題に翻弄されることになります。

Githubにまるっとぶち込む

  1. ファイルを編集してFTPでステージング環境にアップロード、動作確認
  2. 動作が問題なければ、本番環境にFTPでアップロードでリリース完了

私がWordpress運用に関わりを持った当時、開発・実装手順はこんな感じで行われていました。すでにステージング環境と本番環境でのコードは全く別のものとなっており、バージョン管理下に置かれていないコードでの運用は、とても不安になる状態でした。とはいえ、私もまともにWordpressの運用したことがなく、どうバージョン管理するのが正しいのか分からず、まったくの手探りでした。

「Wordpress バージョン管理」などとググると、Gitでテーマファイルのバージョン管理し、プラグインでレポジトリからデプロイを行う方法がいくつか出てきます。それ以上に踏み込んだ記事はなかなか見つかりませんでした。悩んでいても始まらないので、とりあえず何も考えずに全コードをまるっとGithubにぶち込むことにしました。これでいざというときには心置きなくテーマだけでなく、Wordpress本体のバージョンを元に戻す事ができます。

FTPの呪縛

Githubでのバージョン管理を始めるにあたり、コード管理の簡単なルールを設定しました。まずは開発をDockerで準備したローカルのWordpressで行うこと。機能を実装する際には、Gitレポジトリに登録されていない野良ファイルをFTPでローカルに取得して差分を調整し、コーディングを行い、FTPでリリースするといったシンプルなものです。

FTPのリリースの図

バージョン管理に慣れていないエンジニアによる開発が主であった為に、野良ファイルが多く発生。ひどい時には、ステージング、本番、Gitレポジトリの内容が全て違う状態だったので、毎回の差分調整が必須でした。また、ファイルアップロード漏れ等のオペレーションミスや、FTPのアップロード作業で依存するファイルを同時にアップロードできないことにより、サイトがエラーになってしまうことが何度かありました。

野良ファイルに、オペミス、依存ファイルのアップロードタイミング。世間一般的に行われているであろうFTPでのリリース作業ですが、すでに詰んでいました。

Github Actionsによるデプロイ

FTPによるリリース作業のカオス状態をどうにかしなければと危機感を抱えていた当時、GithubのCIをGithub Actionsに乗り換えようという動きが社内で活発になっていました。「Github Actions覚えなきゃだしなぁ」とGithub Actionsによるデプロイを実装してみることにしました。

まず、元々のmainブランチの他に、本番環境リリース用にreleaseブランチを用意しました。開発ブランチのコードで起きなかったエラーが、mainブランチにマージしたコードで発生する可能性に対応する為です。

本番環境リリースまでの流れは次のようになります。

  1. 開発ブランチからmainブランチへのプルリクエスト(以下プルリク)が作成されるか、プルリクが更新されると、Github Actionsのワークフローがトリガーされ、ソースがrsyncでステージング環境にデプロイされます。
  2. mainブランチへのプルリクがマージされると、Github Actionsのワークフローがトリガーされ、ソースがrsyncでステージング環境にデプロイされます。
  3. mainブランチからreleaseブランチへプルリクされると、Github Actionsのワークフローがトリガーされ、ソースがrsyncでステージング環境にデプロイされます。
  4. releaseブランチへのプルリクがマージされると、Github Actionsのワークフローがトリガーされ、ソースがrsyncで本番環境にデプロイされます。

Github Actionsによるデプロイの図

複数人での作業をすると、どうしてもステージング環境のデプロイが被ってしまう為、ステージング環境を作業ブランチで強制的にデプロイする手動デプロイと、いざというときに本番環境用をデプロイし直す為の手動デプロイを準備しました。 必要なサーバー情報などは各Gitレポジトリのシークレットに登録してあり、ワークフローから呼び出されます。また、何かアクションが発生するごとにSlackに通知するようにしました。

これでやっと、Gitレポジトリとステージング、本番のコードの差分をなくすことができました。

イェーイ✌️

WP-CLI

Github Actionsによるデプロイを実装したものの、wp-config.phpの修正はFTPによるアップデートを継続していました。各種パスワードや、APIトークンなどそのままのデータをGitレポジトリ上にコミットできない為です。本番環境・ステージング環境による設定の違いもありなかなか管理の難しいファイルです。本番環境にステージング環境用のファイルをアップロードしてしまうなんて事故も起こってしまい、難儀なやつです。

ところで、皆さんはWP-CLIってご存じでしょうか。

WP-CLI は WordPress を管理するためのコマンドラインインターフェースです。 プラグインのアップデートやマルチサイトのセットアップなどの多くのことをブラウザなしで行うことができます。

とオフィシャルサイトに書かれている通り、Wordpressのサイト設定を行うコマンドラインツールです。メジャーリリースは2016年、現在の安定バージョンは2.5.0。正直なところ、私は最近まで存在を知りませんでした。

Wordpressの設定は、wp-config.phpに記述して行うもの、Wordpress本体が準備している設定ページで編集を行いDBで管理をするもの、プラグインやテーマにより設定ページやプログラム上で編集・設定を行いDBで管理するものがあります。これらすべてをWP-CLIのコマンドで変更できてしまいます。

Github Actionsでのデプロイの際、rsyncの後にこのWP-CLIでSSH越しにコマンドを実行し設定を更新することにしました。レポジトリ内に各環境ごとのシェルスクリプトを準備し、その中にWordpressの設定更新コマンドを大量に記述し、サイト名、サイトURL、DBの設定などの基本的な設定から、プラグインの有効化、テーマの有効化や削除など、多岐に渡る設定がデプロイ時に行われるようになりました。

知らないうちに貯まる更新

Wordpressサイトを管理していて面倒くさいのが更新作業です。複数のサイトを巡回して、更新を見つけるたびにプルリクを作ってマージ、デプロイ。サイトが増えれば増えるほど、この単純作業が他の業務を圧迫していきます。機能追加などがなかったサイトはついつい確認もサボりがちに。

貯まった更新の図

せっかくWP-CLIで各更新やその情報の取得が可能だと分かったので、Wordpressのバージョン、翻訳ファイルのバージョン、プラグインのバージョン、テーマファイルのバージョンをそれぞれ確認して、更新がある場合はプルリクを作成しSlackに通知をする、定時処理のGithub Actionsのワークフローを作成しました。これで更新のSlackに通知がきたら、ステージング環境で動作を確認してマージするだけで、更新作業が完了です。楽ちん。

これだけ自動化してあげると、更新の面倒くささも格段に解消されます!

常に最新の状態の図

さいごに

紆余曲折を経て、バージョン管理すらされていなかった弊社のWordpressサイトは、Githubレポジトリの下しっかりと管理され、安全に更新・デプロイの可能な状態になりました。Wordpressは枯れた技術ではありますが、バリバリに現役で進化を続けているCMSです。ヘッドレスCMSなどの新しい技術でも基幹のシステムとして活躍しています。私も現状に満足せず、弊社Wordpressの運用を改善し続けていきます。

この記事が「Wordpressでこれからサイトを始めるよ」「Wordpressのサイト管理をもっと楽にしたかったんだ」なんて方たちの一つのアイデアとして、お役に立てれば幸いです。機会があれば、Wordpressに関してまた別の切り口でお話する機会があればと思います。

Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています!

エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの?」と気になってくれてた方は、こちらチェックしてみてください!もちろんオープンポジション的に上記に限らず積極採用中です!!!

それでは、さようなら👋