動的テストの自動化を考える#7

今回は「パイプライン」です。Jenkins2.0から標準で使えるようになったとはいえ、この「パイプライン」のメリットは何でしょうか？Jenkinsの「パイプライン」をググってみると、そのメリットの感じ方は人それぞれのようですが、概して「Pipeline as Code」にメリットを感じている方が多いようです。自動化の潮流でCI/CDが当たり前となった昨今、CI/CDを構築する手順も複雑になり、スクリプトをちょっと変えただけでもビルドが通らなくなったり、テストが回らなくなったりしたことが多くなってきていると思います。そこで出てくるのが「Pipeline as Code」という考えです。本ブログのテーマでもある「動的テストの自動化」も、実際に自動化のためのスクリプトを組んでいくと、あれこれ手順が増えていきスクリプトも複雑化する傾向にあります。そう考えると、「動的テストの自動化」にも「Pipeline as Code」という考えはマッチするのではないかと考えました。そこで、今回から3回に渡り「Pipeline as Code」に基づく「動的テストの自動化」の最善の形を考えていきたいと思います。

「Pipeline as Code」とは

よく「○○ as Code」という表現をあちこちで見かけますが、そもそも「Pipeline as Code」とはどういうことでしょうか。一般的に、「○○ as Code」といった場合、「○○をコードで管理する」という意味になります。「○○ as Code」の代表的な例として、「Infrastructure as Code」があります。まずは、「Infrastructure as Code」の考え方から見ていきましょう。

Infrastructure as Code

Wikiによると、「Infrastructure as Code」は次のように書かれています。

Infrastructure as Code（IaC） というのは、物理的なハードウェア構成やインタラクティブな設定ツールの使用ではない。コンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバー、など）の構成を管理したり、機械処理可能な定義ファイルを設定したり、プロビジョニングを自動化するプロセスである。なお、定義されたファイルはバージョン管理システムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている。
出典元: Infrastructure as Code – ウィキペディア

一見、スッと入ってこない表現ではありますが、平たく言えば、「環境構築手順がコード化されていれば、バージョン管理もできるしメンテ作業や検証作業、派生開発への流用が楽になる」ということになるでしょうか。

Pipeline as Code

では、「Pipeline as Code」はどうでしょう。そもそも、「Pipeline as Code」という表現はJenkins 2.0がリリースされた2016年頃から盛んに使われていたことばのようで、最近(2018年9月時点)では、”Pipeline”というと、”as Code”の意味も含んでしまっているのか、本家サイトにある「Jenkins User Document」には「Jenkins as Code」とう記述はありません。しかしながら、「Jenkins as Code」で検索してみると、当時の「Jenkins User Document」の一部なのか、次のような記述が見つかりました。

Pipeline as Code
Introduction
Pipeline as Code describes a set of features that allow Jenkins users to define pipelined job processes with code, stored and versioned in a source repository. These features allow Jenkins to discover, manage, and run jobs for multiple source repositories and branches — eliminating the need for manual job creation and management.
出典元: Pipeline as Code – Jenkins User Document

こちらは、「パイプラインとして実行するJobをコードで制御・管理することで、複数のリポジトリにまたがるJobも一元管理可能」という意味になるでしょうか。
以上のことから、「パイプラインで行う内容とその手順」をコードで管理することによって、「Pipeline as Code」には、「Infrastructure as Code」と同様に、次のようなメリットがあると言えます。

「Pipeline as Code」を「動的テストの自動化」にどう適用するか

「Pipeline as Code」の目指すところとメリットがわかったところで、次は、「動的テストの自動化」に対してどのように適用すべきかを考えてみたいと思います。第2回で示したように、DTシリーズ製品を使用して「動的テストの自動化」のCI環境を構築した場合、図1のような流れになります。

図1: 動的テストのCIサイクル

このCIのサイクルでは、ソースコード取得後の「コードインスペクション」から「テスト結果のアウトプット」まで、大きく7つのフェーズに分かれています。この7つのフェーズは、適度に処理内容が分かれており、各フェーズ毎にパイプラインで実行するJobとして記述すると都合がよさそうです。派生モデルが発生したときの再利用性という意味では、このフェーズ単位で可読性のあるコードを書いておくことで保守性が高まりそうです。では、改めて各フェーズで実行する処理内容を整理してみたいと思います。

各フェーズで行う処理の明確化もさることながら、各フェーズでエラーが発生したとき「どの処理を実行したときに何のエラーが発生したか」を明確に残せる工夫がされていると一段と保守性が高まりますので、次回はこれらを意識したパイプラインのコーディングを行っていきたいと思います。

最後に

今回取り上げました「Pipeline as Code」という考え方ですが、意外と「動的テストの自動化」に向いている思うのは筆者だけでしょうか。「動的テストの自動化」もフェーズ分けしてやるべきことを挙げていくと、改めていろんなことをやっているなとその複雑さを実感してしまいます。たとえ自動化であってもメンテに掛かる工数が増えてしまうと本末転倒になってしまいますので、再利用性の高い「動的テストの自動化」向けの「Pipeline as Code」を構築していきたいと思います。