ここ半年ほど、ソースコードの保守やアップデートについて考える機会が増えました。
きっかけは、年末にLaravelアプリケーションで利用していた Livewire 関連の脆弱性被害に遭ったことです。
それまでは、アプリケーションやプラグインを作っては次へ、また作っては次へ、という形で進めることが多くありました。新しく作ること自体は楽しいのですが、その一方で、作ったまま十分にメンテナンスできていないコードも増えていました。
脆弱性被害をきっかけに、「作ったものをそのまま放置していてはいけない」と感じ、これまで作ってきたコードの総点検を始めました。
Laravelアプリケーション、Electronアプリ、Vimプラグイン、Composerで配布しているパッケージなど、いろいろなものを見直してきました。
その中で、直近ではWordPress公式ディレクトリで公開しているプラグインに対して、Dependabot、GitHub Actions、wp-env、PHPUnit、Playwright、自動リリース、自動デプロイの仕組みを整えました。
今回は、その取り組みについてまとめます。
対象にしたWordPressプラグイン
今回紹介する対象は、以下のWordPressプラグインです。
https://github.com/ytsuyuzaki/beastfeedbacks
このプラグインに対して、WordPress公式の wp-scripts で提供されている仕組みや 10up/action-wordpress-plugin-deploy ( https://github.com/10up/action-wordpress-plugin-deploy ) を一通り整えました。
対応した内容は、大きく分けると以下です。
- lint 系の整備
- テスト環境の整備
- GitHub Actions での自動実行
- タグ作成時のリリース作成
- WordPress.org 公式SVNへの自動デプロイ
単にローカルで動作確認するだけではなく、GitHub上で自動的にチェックし、タグを作成したら公開まで進められる状態を目指しました。
lint 系の整備
まず、wp-scripts で提供されている lint 系の仕組みを整えました。
対象にしたのは、PHPコード、ブロックエディタ用のReactコード、package.json、JavaScript、CSS、Markdown、公開時のテキスト、ライセンス表記などです。
WordPressプラグインでは、PHPだけでなく、JavaScriptやCSS、ブロックエディタ関連のコード、README、ライセンス表記など、確認すべきものが多くあります。バージョン番号だけでも4箇所ぐらい更新すべき所があります。
それらを手作業で毎回確認するのは大変なので、できるだけコマンドで確認できるようにしました。
ただ、最初はかなり大変でした。
少し編集しただけでも lint が失敗することがあり、慣れるまでは「また別のルールで怒られた」という感覚がありました。
一方で、ある程度ルールが整ってくると、AIエージェントに修正を任せやすくなります。
lint のエラーは指摘内容が具体的なので、Codex や GitHub Copilot のようなツールとも相性が良いと感じました。
テスト環境の整備
次に、テスト環境を整えました。
WordPressのテスト環境には wp-env を使いました。
wp-env を使うことで、Docker上にWordPress環境を立ち上げ、プラグインを有効化した状態でテストを実行できます。
テストとしては、主に以下を使いました。
- PHPUnit
- Playwright
PHPUnit では、プラグイン内部のPHPコードの処理を確認します。
Playwright では、実際にブラウザを立ち上げ、ブロックエディタ上での動作確認を行います。
WordPressプラグイン、とくにブロックエディタに関わるプラグインでは、PHPの処理だけ確認しても不十分な場合があります。
実際の管理画面でブロックが作成できるか、エディタ上で想定通りに動くか、表示されている機能が実際に使えるのか、といった確認も必要になります。
そのため、PHPUnit と Playwright の両方を使って、内部処理とブラウザ上の動作を確認できるようにしました。
Dependabot で脆弱性に気づけるようにする
今回の取り組みでは、Dependabot も重要です。
Dependabot を使うことで、Composer や npm の依存パッケージに脆弱性が見つかったときに、GitHub上でアラートを受け取れるようになります。
脆弱性対応で怖いのは、「使っているライブラリを更新していない」「問題があることに気づけないまま放置してしまうこと」です。
もちろん、アラートが来たからといって、すべてが自動的に解決するわけではありません。
それでも、気づける状態にしておくことはかなり重要だと感じています。
脆弱性を検知し、更新PRを作成し、GitHub Actions でテストを実行する。
この流れがあると、依存パッケージの更新にも取りかかりやすくなります。
GitHub Actions で自動チェックする
Dependabot や手動での変更に対して、GitHub Actions で lint やPHPバージョンの最低対応（8.1）と最新（8.5）、WordPressバージョンの直近2種類、それぞれの組み合わせでのテストを実行するようにしました。
これにより、変更を加えたときに、最低限のチェックが自動で走るようになります。
ローカル環境だけで確認していると、確認漏れが起きたり、バージョン独自のエラー、そもそも確認すること自体を忘れたりします。
GitHub Actions にしておけば、push や pull request をきっかけに自動で確認できます。
特に、AIエージェントを使ってコードを書いたり修正したりする場合、自動チェックの存在は重要だと感じました。
生成AIはコードを書く速度を上げてくれますが、そのコードが壊れていないか、既存の挙動を壊していないかは、別途確認する必要があります。
その確認を人間の目だけに頼るのではなく、lint やテストとして仕組みにしておくことで、安心して変更しやすくなります。
タグ作成から自動公開まで
今回の取り組みでは、タグを作成したら公開用のzipを作成し、GitHub Releaseを作成するところまで自動化しました。
さらに、そのリリースzipを使って、 10up/action-wordpress-plugin-deploy を使ってWordPress.org 公式ディレクトリのSVNへコミットし、プラグインを公開する流れも整えました。
WordPress公式ディレクトリでプラグインを公開する場合、最終的にはSVNへのコミットが必要になります。
これを毎回手作業で行うのは手間です。
そのため、GitHubでタグを作成したら、自動的にリリースが作成され、WordPress.org 側にも反映されるようにしました。
流れとしては、以下のような形です。
- コードを更新する
- lint とテストが通るのを確認
- タグを作成してプッシュ
- GitHub Release 、公開用zipが作成される
- WordPress.org のSVNへコミットされる
- プラグインが公開される
この流れができると、更新作業の心理的なハードルがかなり下がります。
自動公開で失敗したこと
ただし、自動公開は最初から安心して使えたわけではありません。
自動公開のテストをしているときに、必要な設定が足りていないプラグインが公開され、画面が真っ白になることがありました。
すぐに再公開して対応しましたが、公開されているプラグインで自動デプロイを試すのは、かなり緊張感があります。
この経験から、最初は利用者が少ないプラグインや、影響範囲が小さいもので試すのがよいと感じました。
自動化は便利ですが、設定が間違っていれば、その間違いも自動で反映されます。
特に公開処理は、テスト環境や確認手順を用意しながら慎重に進める必要があります。
やってみて変わったこと
一通り仕組みを整えてみて、更新作業が以前より気軽にできるようになりました。
以前は、少し直したいところがあっても、「公開作業が面倒」「壊していないか不安」「確認項目が多い」と感じて、後回しにしてしまうことがありました。
今は、変更して、テストして、タグを作成して、公開する流れが見えています。
そのため、「直したい」と思ったときにすぐ着手しやすくなりました。
また、自分の発想をすぐ形にしやすくなったとも感じています。
保守の仕組みがあることで、変更に対する不安が減り、コードを書くことにも前向きになれます。
まだ課題として残っていること
一方で、課題もあります。
特に、npm のライブラリに依存しすぎている面は気になっています。
今は wp-scripts や関連パッケージを使うことで、かなり多くのことができます。
ただ、この分野は変化も速く、今の定番がずっと続くとは限りません。
今はこの方法でうまくいっていても、すぐに次の定番や別のやり方が出てくる可能性があります。
そのため、あまり追いかけすぎず、必要な範囲でほどほどに使っていきたいと考えています。
自動化のために複雑になりすぎると、それ自体の保守が大変になります。
保守を楽にするための仕組みが、逆に負担にならないようにすることも大事です。
生成AI時代だからこそ、保守の仕組みが必要になる
最近は、生成AIによってコードを書くことがかなり簡単になりました。
Codex や GitHub Copilot のようなツールを使うことで、これまでより速くコードを書けるようになっています。
これはとても便利です。
一方で、作る速度が上がるほど、保守されないコードも増えやすくなります。
アプリケーションを作ることはできても、その後の公開作業、アップデート、脆弱性対応、テストまで継続できなければ、結果的に放置されたコードが増えてしまいます。
だからこそ、生成AIでコードを書く時代には、保守の仕組みもセットで必要になると感じています。
- Dependabot で脆弱性に気づく。
- GitHub Actions で lint やテストを実行する。
- wp-env でWordPressのテスト環境を作る。
- PHPUnit や Playwright で動作を確認する。
- タグ作成から公開までを自動化する。
こうした仕組みがあることで、生成AIを使った開発も、より安心して進めやすくなります。
公式ディレクトリに公開しない場合でもアップデートは考えたい
今回は、WordPress公式ディレクトリに公開しているプラグインを対象にしました。
公式ディレクトリに公開している場合、WordPressの管理画面からアップデートできる仕組みに乗せられるため、利用者にとっても更新しやすくなります。
ただし、すべてのプラグインやテーマを公式ディレクトリに公開するわけではありません。
自分用のプラグイン、クライアント向けのプラグイン、公式ディレクトリには出しにくいテーマなどもあります。
その場合でも、WordPress用の plugin-update-checker などを使えば、独自配布のプラグインやテーマでもアップデートしやすくできます。
WordPressでは、管理画面から更新できること自体がかなり重要です。Laravelで更新するための仕組みを作ったときには必要な工数が多すぎてかなり手間を感じて、ブラウザ上でアップデートができる事がどれほど多くの手間をかけてどれほど多くの課題を解決してきたのか、手間を省くためには既存のこのサイクルに乗せるのはとても魅力的です。
配布方法にかかわらず、作ったものを継続的に更新できる状態にしておくことは、保守のしやすさにつながります。
まとめ
これはただのGitHub Actionsやテストを設定したという話ではありません。（Hello Dolly風 https://ja.wordpress.org/plugins/hello-dolly/ ）
自分にとっては、作ったものを放置せず、継続的に保守できる状態にするための取り組みでした。
年末の脆弱性被害をきっかけに、作ったままになっているコードを見直し、Dependabot、GitHub Actions、wp-env、PHPUnit、Playwright、自動リリース、自動デプロイを整えてきました。
その結果、更新作業への不安が減り、変更にも取りかかりやすくなりました。
生成AIによってコードを書く速度は上がっています。
だからこそ、これからは「どう作るか」だけでなく、「どう保守し続けるか」も重要になっていくと感じています。
- 作ったものを安全に更新できるようにする。
- 脆弱性に気づけるようにする。
- テストで最低限の確認ができるようにする。
- 公開作業を手順化し、自動化する。
そうした仕組みを整えることで、WordPressプラグインの開発や保守を、もう少し安心して続けられるようになるのではないかと思います。
コメントを残す