投稿者: 福岡 典幸

こんにちは。福岡です

ご無沙汰になってしまいましたが、最近に調整していた開発環境の話を紹介します。いろんなPHPのバージョンで動くか検査する方法です。

PHPバージョンの対応状況

WebClass は Debian と RHEL をサポートしています。具体的には、両者について OS の側でサポートされている期間の間、WebClass も動くように維持するというポリシーです。したがって、サポートする PHP バージョンもこれらOSが現在サポートしている範囲になります。

正直なところ、特に RHEL はメジャーバージョン単位のサポート期間が長くてしんどいです。RHEL 6 の PHP 5.3 はようやく去年にサポート・メンテナンス２が終了しました( REF:Red Hat Enterprise Linux 6 （RHEL6） のサポート終了と移行について)。これで 5.3 が消えると思いきや、RHEL 7 は PHP 5.4 !! 。PHP 5.4 の最初のリリースは 2012年 3月でして、これももう10年になろうとしています(REF: Version 5.4 changelog)。なお、Debian 11 が先週にリリース(REF)されたため、これから PHP 7.4 の対応等を進めていくことになります。

どうやって PHP 5.3 - PHP 7.4 で動くように確認するのか？ これが問題です。

昔は、それこそ Debian 8 と Debian 9 と CentOS6 と、という感じで複数のサーバを構築していました。ですが、機能も増えてきている今の WebClass を1つ1つ手でチェックしていくというのは無理です。ベテランプログラマーはバージョン依存が出にくい PHP のコーディングスタイルを身につけていますが、新しく加わった人がそれを身につけるものしんどいし、レビューでもチェックしきれません。実際のところ、バージョン依存の問題をポロポロと出してしまっています。

そこで、検査と開発者へのフィードバックの機械化を進めています。

PHP Unit による自動テスト

WebClass ではアジャイルな開発スタイルを採用しています。開発作業の流れとしては、社内の GitLab を使って Issue => Merge Request => Merge を繰り返しています。そして、このイテレーションでは GitLab の継続的インテグレーション機能を使って、テストとパッケージングを機械化し、素早く完全な変更を繰り返していくことを意識しています。自動テストの一部は PHP Unit を使っており、継続的インテグレーション機能（Pipelie)は次のような感じです。

PHP Unit の実行環境として、それこそ少し前までは Debian のサーバを構築していました。その後にテスト用のサーバの維持などの問題で CI での自動テストの運用が止まってしまいましたが、そうするとやっぱり開発者が自分でテストをするというのは、どうしてもおろそかになります。そこで、CI-Runner が使う Php Unit 実行用の docker イメージを作り、メンテナンスが後手に回ったテストを直し、今では Merge Request を発行するたびに自動的に Php Unit の結果がフィードバックされるようになっています。

PHP のバージョンごとにコンテナイメージを追加することで、複数のPHPバージョンで並行して自動テストを行うことができます。今は PHP5.6 と PHP 7.3 の環境で自動テストが走っています。

一方、Php Unit さえあればいいかと言うとそうでもありません。自動テストが実装されていないところはテストされないのが何より問題です。WebClass は2000年から開発スタートして、今まで完全な作り直しはありません。ですので、フレームワークのない状態から今まで拡張の傍らで必死にリファクタリングを進めて構造化し、後から自動テストスイートを加えて、そこからテスト可能な実装にリファクタリングしてテスト実装して、と走ってきました。まだテスタブルでないコードも、自動テストが実装されていないコードも残っています。

CI に PHP Linter 追加

Php Unit は自動テストが実装されないとコードを検査できませんが、PHP のコードの文法レベルであればすぐにスキャンできます。文法レベルの問題としては、例えば以下があります。

// PHP 5.4 から使える。それ以前のバージョンでは文法エラー
$array = [ 1, 2, 3];
// この書き方はどのバージョンでも使える
$array = array( 1, 2, 3 );

この程度と思いきや、文法エラーは PHP をロードした時点でエラーになって落ちるので、初期の require() などで１つでも混入すると機能が全く動かなくなります。ですので、検査する価値はあります。

PhpLinter のライブラリもいくつか公開されていますが、中を除くと基本は PHP に実装されている Lint 機能を使っているようです。この機能はコマンドラインで php -l test.php と実行して検査できます。ということは、 PhpUnit を動かせるコンテナであれば、composer とか phing を使うまでもなく以下のコマンドでチェックできます。

find $SRCDIR  \( -type f -name "*.php" -o  -name "*.inc" \)  -exec php -l {} \; | grep -v 'No syntax errors detected' 

ということで、準備しました！

PHP 7.4 で早速 PhpUnit が落ちています。また、UnitTest のJob に 7.0 などがいないのは、まだ調整中のためテストJob を入れたり外したりしているからです。

自動テストに失敗していれば、Merge Request 画面でもその結果が表示されて、マージできなくなります。

テストターゲットのチューニング

Lint を実行するコマンドは、実は PHP のバージョンごとに用意してあります。

これは、大学に提供しているカスタム機能などがその大学での実行環境に依存していることが有るためです。このように、もともと特定の環境で動くことを想定しているコードがどうしてもあるのと、新しいバージョンに対応させていく優先順位はありますので、全てを一気にとは行きません。このタイムラグを解決するための苦肉の策です。

composer の overtrue/phplint などのツールもあり、phplint ツールのコンフィグファイルを書き分けるても有るのですが、それはやめました。理由は２つ。１つは、PHP バージョンごとに実行環境を分けているので、PHP バージョンが古いと composer の使いたいライブラリやバージョンを使えなかったりして返ってややこしい。１つは、php -l は Deprecated などの情報もバリバリ書き出してくれるので、将来のバージョン対応を見据えて Error ではない情報もチェックするときに便利なため。こういうときには良くも悪くも Bash は単純で、除外リストなど開発者がそのまま読んだり調整しやすいと思ったからです。

まとめと今後

PHP のバージョンごとのテスト用 Docker がひとまず揃いました。CI でも動かしますが、Docker なので開発者の手元でもすぐに動かせます。まずはこれで PHP の文法レベルの問題は未然に防げるようになると期待できます。

さらにテストの内容を充実させるために PHPUnit のテストはどんどん書き足していきます。そのため、Merge Request のレビューではテスト可能な設計になっているか、テストの内容は十分か、なども引き続き突っ込んでいきます。

また、レビューにおける脆弱性の検査もなかなか難しいため、GitLab の SAST 機能あたりに興味を持っています。よく見ると PHPについては PHP-CS の拡張パターンのようですが。

https://git.lan.datapacific.co.jp/help/user/application_security/sast/index

小さなチームでレガシーコードも抱えていますが、うまくやりくりして良くしていきます。