testing - 継続的インテグレーションでは、テストがコミット前ではなくコミット後に実行されるのはなぜですか?

Question

私は (単独で) プッシュする github リポジトリしか持っていませんが、テストを実行するのを忘れたり、関連するすべてのファイルをコミットするのを忘れたり、ローカル マシンにあるオブジェクトに依存したりすることがよくあります。これらはビルドの中断につながりますが、誤ったコミットの後に Travis-CI によってのみ検出されます。TeamCity にはコミット前のテスト機能 (使用中の IDE に依存) があることは知っていますが、私の質問は、1 つの実装ではなく、継続的インテグレーションの現在の使用に関するものです。私の質問は

Travis-CI がコミット後のテストに使用するマシンなど、変更がコミットされる前に、クリーン ビルド マシンで変更がテストされないのはなぜですか?

このようなプロセスは、ビルドの中断が発生しないことを意味します。つまり、新しい環境がリポジトリからコミットをプルし、その成功を確認できることを意味します。そのため、コミット後のテストを使用してCIが実装されていない理由がわかりません。

Answer 1

コードを記述してコンパイルし、テストがローカルで渡された場合、ビルドが壊れる可能性はないという仮定は間違っています。あなたがそのコードに取り組んでいる唯一の開発者である場合にのみそうです。しかし、あなたが使用しているインターフェイスを変更したとしましょう。私のコードは、私のインターフェイスを使用する更新されたコードを取得しない限り、コンパイルしてテストに合格します。インターフェイスで私の更新を取得しない限り、コードはコンパイルされ、テストに合格します。二人でコードをチェックインすると、ビルド マシンが爆発します...

したがって、CI は基本的に次のように言うプロセスです。できるだけ早く変更を加えて、CI サーバーでテストします (もちろん、最初にローカルでコンパイルしてテストする必要があります)。すべての開発者がこれらのルールに従っている場合でも、ビルドは壊れますが、遅かれ早かれわかります。