4 ms·
In terms of an asset being software that you're deploying, I don't get this attitute. If the process for producing the software is unreproducible, then you're
by cbaines 6y ago
In terms of an asset being software that you're deploying, I don't get this attitute.
If the process for producing the software is unreproducible, then you're running the risk that the behaviour of the software will be unreproducible. As in you run the generation process once, and then again with the same inputs, and you'll get an output that works differently.
Now of course you can store the generated asset, which gives some certainty in the roll back case. But roll backs are hopefully rare, what's more common is to make small changes to inputs (like source code changes), and hope that the generate asset has only been affected by the intended change.
To give an example of how this works where no care has been taken that the process is reproducible, I've seen people try to make code changes to Docker images, and end up with changes that they didn't intend (like a different version of Debian in the image, or a different Ruby/Python version).
- jacques_chester 6y agoI think I misunderstood your emphasis. I've seen folks position reproducible builds as the best and only solution to trust and integrity problems; I buttonholed you as the same. I do appreciate the general benefits of controlling the factors which go into an asset. Build reproducibility is a standard that requires a high capability to track and control your assets. In that respect it's an excellent goal. Recapping: I say yes to reproducibility as a practice, but I don't see it as a substitute for an accounting mechanism. They're complementary.