CIで既存のビルド成果物を再利用するには、今回の変更がその成果物に影響しないと判定できる必要がある。ソースの変更だけでなく、依存関係、ビルド設定、コード生成の入力など、成果物を変える要因まで判定対象に含めたい。
Slackは、フロントエンドに変更がない場合、E2Eテスト用のビルドを省き、本番で稼働中の比較的新しい成果物をS3から選んで社内CDNで配信するようにした。変更の判定と成果物の探索は平均3秒未満で、ビルド頻度は60%減ったと報告している。
https://slack.engineering/speedup-e2e-testing/
この事例から考えたいのは、変更検出の正しさも検証の正しさの一部になることだ。成果物に影響する変更を見落とすと、古い成果物を使ったテストが通っても、変更後の成果物を検証したことにはならない。フロントエンドのソースが変わっていないという条件だけで十分かは、そのビルドが何を入力として使うかによって決まる。
再利用する成果物とテスト対象の組み合わせも、検証したい条件に合っている必要がある。変更後のバックエンドと本番のフロントエンドの互換性を確かめたい場合と、マージ後のソース全体から作った組み合わせを確かめたい場合では、適切な成果物が異なる。記事は、Slackでの変更判定対象や互換性の保証方法を詳しく公開していない。
再利用の効果は、変更検出と成果物の取得にかかる時間を含めて、待ち時間とランナー時間を分けて測る。再ビルドを省ける条件が明確なら、検証範囲を保ちながら準備処理を減らせるため、変更から検証までの短いフィードバックループにもつながる。