A factory runs a quality model and a maintenance model on one build server. Upgrading a numeric library for the quality model changes results for the maintenance model, which never requested that upgrade. Which practice stops one project's library change from altering the other?
Select an answer to reveal the explanation.
Short Explanation
Two kitchens that share one spice jar will taste each other's experiments. You isolate dependencies so a library upgrade for the quality model cannot change the maintenance model's results. The trap is one shared environment that ships a single upgrade to every project on the server.
Full Explanation
The maintenance results changed because both projects resolved the numeric library from the same place, so the quality project's upgrade landed in a project that did not take it. Dependency isolation gives each project its own library set, or its own environment, so resolving and upgrading libraries for the quality model does not change what the maintenance model imports. A single shared environment is the current failure: one upgrade reaches every project on purpose. Pinning only the operating system leaves the numeric library free to move, and both projects still import whatever was installed last on the host. Copying the upgrade into a global folder both projects import is the shared path that caused the leak, not a barrier between them. Exam caveat: isolation does not remove the need to test an upgrade inside the project that wants it; it stops that upgrade from arriving in a project that did not take it. Operational check: upgrade the numeric library in the quality environment and confirm the maintenance environment still resolves the previous version.