こんにちは、技術部の taiki45 です。3月17日に ICST 2017 の参加者などを招いたミートアップがあり、そこでクックパッドの開発とテストへの取り組みについてお話をしました。この記事では資料とセッション中に行われた質疑応答を元に、発表についての補足をしたいと思います。このミートアップについては、後日開催報告記事が出る予定です。
今回はクックパッドをご存知ない方に向けて、クックパッドでのテスト領域での取り組みについて紹介しました。そのため、前半部分では後半への橋渡しとして、クックパッドがどういうことに取り組んでいるか、またクックパッドでのソフトウェア開発の規模や様子について俯瞰した視点でお話しました。
特に今回の話では、分散型アーキテクチャを選択した際に起きる問題が主題だったので、チーム構成とシステム構成の面を説明しました。具体的には、事業領域に沿ってチームが分割されていること、システムもチームの分割に沿うように分けられていて、システム同士が協調して動作する構成になっています。
プロダクトの規模について紹介をしている場面で、月次利用者数とともに “プロダクトとしての Cookpad” だけでのテストケース数をお話した際には、「そのケース数は自動テストのみを数えているのか？」「自動テストのみです」といったテストエンジニアの集まりらしいやりとりをしました。また、その数のテストケースを実行している仕組みについて質問があったので、分散テスト実行システムである RRRSpec について説明をはさみました。
「ビルドとリリース」については、コードレビュー後のマージによって自動テストジョブがキックされ、その後の Docker イメージのビルド、開発環境サーバーへのデプロイ、本番環境同等のカナリアサーバーへのデプロイが自動で行われています。カナリアサーバーへのデプロイ後は、カナリアサーバーに対してスモークテストが自動で実行され、さらに必要に応じて開発者による動作確認が行われます。本番環境へのデプロイは細かい粒度で行われています。リリース対象の機能やバグ修正に責任を持つ開発者が明確になっているので、開発者の責任でデプロイ後の動作確認をしています。問題があれば開発者がロールバックを行います。
テストに関する取り組みについては、「実践 Pact:マイクロサービス時代のテストツール」で紹介したことと同じく、Consumer-Driven Contract testing パターンを適用したことについて紹介しました。Pact の仕組みについては特にデータセットアップに関する質問が多く、質疑応答や後の懇親会等で「本番環境は使用せずテスト環境で Provider 側のテストを実行すること」や「"Provider States" という仕組みでデータセットアップ処理に名前をつけて Provider 側でテスト時にデータを用意すること」を補足しました。
