DockerのコアチームメンバーであるJessie Frazzelle氏は、Dockerのテストインフラを担当している。彼女はテストインフラがDockerコンテナ上にどう構築されているか説明した。
テストインフラは約50のサーバで構成されている。テストインフラは6つの異なるストレージドライバを用い、Dockerのコンテナ格納方法、DockerがサポートするすべてのLinuxディストリビューションとさまざまなLinuxカーネルバージョンを決定している。Windows上でDockerホストを動かすための軽量VMを提供するWindows Dockerクライアントもある。
masterへのプッシュとプルリクエスト(PR)には独自のワークフローがある。Dockerテストをすべて実行するのに加えて、masterへのプッシュが成功するたびに、最新版を試したい人向けにDockerのバイナリとドキュメントを生成する。Docker Binary Builder (docker-bb) がmasterバイナリの構築を処理している。
プルリクエストには独自のワークフローとサーバがある。それぞれのプルリクエスト - 毎週100以上ある - はDockerテスト、新しい実験的バイナリ、Windows Dockerクライアントに対して実行される。すべてのPRビルドの管理には、彼女が構築したLeeroyという小さなアプリが使われている。その責務には、PRの状態（ペンディング、成功、失敗あるいはエラー）の更新と、Docker Developer Certificate of Originの検証が含まれる。
Dockerは継続的インテグレーションサーバにJenkinsを使っている。これはチームが必要とする柔軟性とコントロールを提供してくれるためだ。当然ながら、彼女は公式イメージを使ってコンテナ内でJenkinsを実行している。
Consulというサービスディスカバリツールがテストインフラの重要なパーツとなっている。彼女はこのサービスのタグ付け機能を使って、Linuxカーネルバージョンやストレージドライバといったデータをトラックしている。これはトラブルシューティングにも有用だ。Consulのヘルスチェッキングは、consul-alertsを使ったチームへのサービスダウン通知にも利用されている。
Dockerチームは、GitHubフックをdocker-bbにリンクしたりmasterドキュメントをデプロイするなど、これら多数のプロセスを統合するのに、リアルタイム分散メッセージングプラットフォームnsqを使っている。
テストインフラを実現するサービスはすべて、Dockerコンテナ内で実行される。テストインフラはそれがあればいつも最新のDocker Release Candidateを使っている。できるだけバグを早く捕捉するため、最新のmasterバイナリを使うこともある。