> When something breaks you log in to the machine and make incremental updates to fix it, right? Not generally, and you do a good job explaining why I don't in

> When something breaks you log in to the machine and make incremental updates to fix it, right? Not generally, and you do a good job explaining why I don't in your next sentence. > This approach leads to non-reproducible deployment environments. It's true that there's some discipline involved, but it's not necessarily a huge amount. For me, what it tends to look like is a build that produces some sort of deployable artifact, an idempotent install script, and following standard Unix patterns. Except for maybe that last bit, this is exactly what you'd do in a Docker environment. And of course, Docker and the like are always still candidates for adoption, if the circumstances warrant. Part of what surprises me about conversations like this is that the idea of an environment in a known and stable state isn't a novel development. The question is really about what degree of environment stability you need to achieve to meet your requirements and then the specific tools and procedures you choose to adopt to meet that goal. Docker is once choice, but not the only choice, and even if you chose it, there is still a set of disciplines and procedures you'll need to follow manually for it to be effective.