再現性のあるビルド

継続的インテグレーションのファンが持つ一般的な前提の一つに、ビルドは再現可能であるべきだという考えがあります。 これは、いつでも、作業中のシステムの古いバージョンを取り出し、当時と同じようにソースからビルドできることを意味します。

これは、私が通常ビルドプロセスについて参照する資料では、重要なプラクティスとして明示されていません。 それは、基礎となる前提、つまり説明するまでもなく明白であると考えられているためだと思います。

再現性のあるビルドを持つ主な理由の1つは、まだ使用されている過去のリリースでの問題に対処できるようにするためです。 1年前に顧客にソフトウェアをリリースし、現在、深刻なバグが報告された場合、修正を提供できるように、そのソフトウェアを再作成できることが重要です。

しかし、毎週ホスト環境にソフトウェアをリリースしているケースを考えてみましょう。 また、しっかりとした継続的デリバリープロセスがあり、次のリリースまで待つか、(本当に重要な場合は)早期リリースを行うことでバグ修正を広めることができると確信しているとしましょう。 その場合でも、再現性のあるビルドは必要でしょうか？

バグレポートを受け取り、ヘッドでバグを再現し、ヘッドで修正し、待機するか即時リリースするシナリオでは、必要ありません。 しかし、再現性のあるビルドが非常に役立つケースはまだあります。

バグレポートを受け取ったが、再現できない場合はどうなりますか。 修正済と宣言して次に進みますか？ 私はその対応には満足できません。 まず、バグを本当に理解したいので、リリースされたバージョンのソフトウェアをチェックアウトし、ビルドして、それを再現できることを確認したいと思います。 バグを再現することに自信を持つには、ビルドを再現する必要があります。 さらに、最近の開発中にバグがen passantに修正されたと確信している場合でも、少なくとも1つのテストが不足していると主張します。 そのテストを作成し、現在パスすることと、リリースされたビルドに対して失敗することを検証したいと思います。

もう1つのケースは回帰です。 お客様から、以前はなかったバグが現在あるという連絡が来ます。 このようなバグは、発生してあなたに触手を振るまで長い間隠れている可能性があります。 たとえば、毎月1日が月曜日の場合にのみ発生するかもしれません。 いずれにしても、2か月前には機能していたと思うソフトウェアにバグが発生しました。

ここで、再現性のあるビルドがあると、DiffDebuggingを使用できます。 お客様は、2か月前にはこの問題がなかったと確信しており、それはビルド20000で、現在はビルド28000です。 そのため、ビルド20000をチェックアウトして、バグがあるかどうかを確認します。 そうではないので、ビルド24000を試しますが、そこにもありません。次に26000です。すぐに、バグが最初にリビジョン26543で発生したことがわかります。（最新のバージョン管理システムには、役立つ機能があります）。次に、リビジョン26543とその親の間の差分を確認します。多くの場合、このアプローチの方がバグを見つけやすくなります。