CI/CDパイプラインがなくともテスト自動化は行えるし、CI/CDパイプラインはテスト地獄で開発効率が低下しがちだよ

CI/CDパイプラインは、バージョン管理システムへの変更反映をトリガーに、アプリケーションの①ビルド、②テスト、③パッケージング（含コンテナ化）、④デプロイを自動実行する手法で、インハウス開発でウェブサービスを作っていて、DevOpsになっているところで流行っている。

人海戦術的なテストが自動化され、その効率化によって開発速度があがると言うような説明がよくされているのだが、CI/CDパイプラインをせずともテスト自動化は行われてきた。むしろ、CI/CDパイプラインの導入でテスト地獄が顕在化し、開発効率が低下するケースもある。

ビルドとテストの自動化はCI/CDパイプライン導入の要件であって御利益ではない。GitHub ActionsやJenkinsのようなCI/CDツール（サービス）は、プロジェクト管理ツールを動かすだけ。プロジェクト管理ツールが、ビルドの自動化、テストの実行、パッケージングを行う。テストはテスティングフレームワーク（JUnit）を使って、プログラマーが実装する必要がある。Javaでは例えばmvn packageと一行打ち込めばパッケージングまでの作業が完了するようにした後、CI/CDパイプライン導入する。

CI/CDパイプライン導入御利益は、テストが済んでいない変更をソースコードのリポジトリーに入れるのを防止できる点になる。テストしてからプッシュしろと言う開発リーダーの説教とコミット取消処理を自動化できるのが御利益。サーバー管理者不在でも検証環境（ステージング）や実稼働環境（ほんばん）を更新できるのも、融通の効かないサーバー環境であれば利点になる。http(s)でアップロードして展開実行できるJavaのWARは忘れておこう。

開発速度が上がるかは分からない。CI/CDパイプラインが掲げる理想は品質保障のオートメーション化なので、テストコードの本数が増えるし、Seleniumのようなブラウザーオートパイロットツールで結合テストをする必要も増すので、テストコードの作成とメンテナンスの負担が増えるし、テストの実行時間が増える。開発速度はむしろ低下する場合も多々ある。

テスト地獄が生じて、あからさまに開発の邪魔になる場合もある。変更をプッシュしたら、テスト完了まで一時間ほど待たされる。テストコードの品質が低くて、同じコードでテストが通ったり取らなかったりする^*1。そのため、変更がリポジトリーに反映される頻度が落ち、チーム内のコード共有にラグが生じている。こんな惨状の開発現場もあるようだ。常にすべてを実施する必要はないプロジェクト管理ツールと異なり、CI/CDパイプラインのテストはプッシュと連動しているので、テスト実施回数が増えてしまうし、テストとテストの競合が顕在化しやすい。

現実的に「ビルドできないコードはプッシュするな」「テストしてから（プレ）リリースタグをつけろ」と言うように方針を後退させ、CI/CDツールの設定を緩めることになると思うが、一ヶ月に一回しかタグをつけないのであれば、サーバー管理者がファイルコピーするような作業手順に対して、さほど省力化されない。プロジェクト管理ツールの設定がしっかりされていればCI/CDパイプラインの導入が大変と言うことはなく、利点は利点でしっかりあるので使っていけばよいとは思うが、省力化の銀の弾丸のように思っていると拍子抜けするし、教条的に運用しようとするとテスト地獄で立ち行かなくなるので注意しよう。

*1flaky testと呼ばれているが、データベースがひとつしかないのに複数のテストを同時に走らせると、最初のテストが前提とするデータベースの状態が、次のテストによって書き換えられて維持できないと言うようなことが生じるそうだ。