ConcouseCIによるテスト駆動コンテナ化ビルドパイプライン

ThoughtWorksの主任開発者のひとりが、同社のあるクライアントでビルドパイプラインを書き換えた際の、自身のチームの経験談を公開している。チームは、コンフィギュレーション・アズ・コード、パイプライン駆動デリバリ、コンテナのサポート、システムの可視性といった点を重視して、JenkinsからConcourseCIへのスイッチを行った。

既存のシステムは中央にJenkinsを配置し、複雑に構成されていた。パイプラインは内部のDSLで記述されていたが、所有権がチーム全体に分散しており、実際の所有者は存在しなかった。セットアップ変更は大変な作業で、作り直すことはほぼ不可能に見えた。

チームはまず、新たなシステムに望むものをリストアップした。インフラストラクチャ・アズ・コードの考え方を導入するためには、構成情報をバージョン管理の下に置く必要がある。新たなシステムは、ビルディングブロックとしてパイプラインをサポートし、コンテナをサポートし、ステータスが容易に視認可能な、成熟した、メンテナンスの行き届いたツールでなければならなかった。一般的なアプローチは、集合的所有権(collective ownership)を持つ新しいCIシステムを導入することだ。いくつかのツールを評価した後、チームは、UIのシンプルさと宣言的構成の容易さから、ConcouseCIを選択した。この移行作業は、マネージドデータベース – Amazon RDS – とAWSオートスケーリンググループによる計算処理に移行するという、大規模なアーキテクチャ再編作業の一環として実施された。

チームが最も重視したのは、迅速なリリースを実現することだった。 可能な部分でのパイプラインの並列化、複数のリンタ(linter)、ユニットテストとインフラストラクチャテスト、デリバリ対象のコンテナ化などが、これを実現する上では重要な役割を果たした。さらにコンテナは、運用時のアプリケーション実行とビルドパイプライン自体の実行の両方において、安価な分離メカニズムとしても使用された。

InfoQは、ThoughtWorksの主任開発者で記事の筆者であるMario Fernández氏とコンタクトを取り、マイグレーションの詳細とコンテナの利用について詳しく聞くことができた。

２つのコンテナには異なる目標があります。運用コンテナはアプリケーションを実行するためのものなので、インストールするソフトウェアを最小限にして、フットプリントとソフトウェア面での脆弱性を低減したいと考えています。これらのコンテナは、すべてAlpineをベースとしています。ビルドコンテナは、ソフトウェアをビルドし、実装の必要なチェックがパスしていることを確認するためのものです。こちらについては、最適化はあまり必要としないので、もう少し穏やかなものになります。

ConcourseCIパイプラインはYAMLで定義されており、ジョブ(パイプラインの動き方)とリソース(ジョブが使用するオブジェクト)という抽象概念で構築されている。今回のパイプラインは、独立してテスト可能なシェルスクリプトを中心に構成された。タスクの複製を避けるため、パイプラインタスクにはパラメータ化による再利用が行われた。パイプラインの一貫性を保つように最初から取り組んでおくことで、後の再利用が容易になった、とFernández氏は述べる一方で、過度な共通化については警告している。

問題が表面化するまでは、あまり多くの時間を投入しないようにしています。必要ではなかった複雑性を組み込むことになる場合があるからです。ですから私は、問題をしばらく放置するようにしています。最初にタスクの複製が発生した時点では、共通化のために投資する価値はないかも知れません。しかし、それが一般的なものになってくると、メンテナンスの作業量が増加する、あるいはアップグレードが難しくなるなど、チームの負担になる場合があるのです。

このような再利用の例としては、独自のリポジトリにあるタスクライブラリがある。このライブラリは、アプリ固有の要件をビルドスクリプトにする形で、ビルドステップの標準化を促進する意味も持っている。ただし、bashビルドスクリプトはモジュール化が難しいため、ほとんどのプロジェクト間で複製されている、とFernández氏は説明する。別のスクリプト言語に乗り換えれば、必要のない技術的依存関係が発生する可能性がある。TerraformやServerSpecを実行する非アプリケーションコンテナのビルドにも共有モデルが適用されたが、アプリケーションコンテナは分離されたままとなっている。

テストスイートはTypescript、CSS、Terraform用の複数のリンタファイルとDockerファイル、ヘッドレスChromeテストで構成される。インフラストラクチャ用のテストフレームワークであるServerSpecでは、インフラストラクチャリソースが期待どおり動作していることを確認できる。この場合、ConcourseCIは自身のビルドをコンテナ内で実行するため、これらのテストはDocker-in-Dockerを使ってコンテナ内でコンテナを実行する。

集合的所有権は、この取り組みの目標のひとつだ。ただしこれは白と黒の問題ではない、とFernández氏は言う。

システムに関して、今回の場合はCIですが、他より詳しい人は常にいるでしょう。私たちは知識のサイロが作られるのを回避しながら、そういった人たちに対して、自分の好きなことに取り組む機会を提供したかったのです。たくさんのペアリングを行って、全員が折りに触れてプロダクトのあらゆる部分に関われるようにすることが、知識の普及には役立ちます。その間は、ある分野について他より多くの知識を持っている人たちが“アンカー(anchor)”となり、開発しているものの品質の高さを保証します。オープンかつ頻繁な共有もまた、この活動では有効です。

チームメンバの離脱は、集合的知識にリスクをもたらす可能性があるので、デリバリとコーチングの両方を重視することが重要になる。利害関係者はトレードオフを理解しなければならない。デリバリのみに注目すると、“チームメンバの離脱を乗り越えられない、アンバランスなチームになる”リスクがある、とFernández氏は言う。“知識の拡散とチームのスキルアップは、通常の開発プロセスの一環として組織的に行う必要があります。”

このプロジェクトの運用インフラストラクチャはAWS上で動作しており、アクセス管理にAWS IAMを使用している。ConcourseCIは、Terraformスクリプトが使用するAWSインフラストラクチャ生成の権限を持ったロールで実行される。Concourseそれ自体はEC2インスタンス上で動作し、パイプラインフローを視覚化するダッシュボードを持っている。移行作業では、JenkinsとConcourseの違いへの適応、新しいCIの複雑なセットアップ要件とドキュメント不足など、いくつかの問題が発生した。