the data source password for this specific environment has been customized and set to a new value.
Recording this information is critical because it is very hard to be able to intelligently and correctly adapt an application's state - when upgrading to a new version, for instance, or adding new servers to the target cluster - if you do not know where the application is currently running.
If we are going to achieve hassle-free, push-button deployments, another thing we will have to reconsider is whether we really need to tweak and customize our infrastructure in every way possible. Indeed, some companies seem to almost have a policy that any setting that might be a default should be regarded with suspicion and, preferably, changed.
Much as custom project layouts made setting up a build unnecessarily tedious and complicated in a convention- and model-based system, stubbornly refusing to go with infrastructure defaults will make it harder to get hassle-free deployments that truly cover all the steps required.
Sticking with defaults not only encourages reusability because the chances are much higher that a solution developed for a different scenario will also work in yours. It also improves maintainability and cuts down on the risk of "ripple" changes, where a custom value in the setting for the servers hosting application X requires further changes to the setup of application Y etc.
Support a "clean build"
When building a large project, we try to cut down on the time taken by recompiling only the source code that has been modifying. When deploying applications, we similarly want to save time when upgrading to a new version, especially when this time represents production downtime.
However, we also know that, eventually, some parts of any incremental build will end up going out of sync, causing strange compilation problems, or features or fixes not appearing when they should.
What do we do in such a case? Do we laboriously try to track down the files that are out of sync and rebuild piece by piece? No, we simply run a clean build to start from scratch, because in 99% of cases it's much quicker to simply rebuild than try to track down the cause of the problem.
In deployment-land, we seldom have the ability to clean build, and this is one of the main causes for the stressful, time- and resource-consuming troubleshooting hunts that are still far too common. Of course, in order to clean build a system we need full versioning of the environment, its configuration and the applications deployed to it. Virtual appliances and virtualization solutions with snapshot capabilities will have a major role to play here.
We also need a known state for durable resources such as databases, which remains challenging but is being addressed by a growing number of products out there.
Push button deployments
Taking stock, it's clear that there is still some way to go. We're slowly developing a common model, but both "(Re)discovering vanilla" and "Supporting a "clean build" are visions not quite yet on the horizon of most large companies.
In fact, it's not so much technological advances that are required - many startups are pretty close to push-button deployments and continuous delivery. Indeed, the "poster children" of this movement already have setups where every commit can pass through an entire regression, integration and performance testing suite and potentially go straight to production.
No, the important hurdles to be taken are procedural and mental, changing rusty ways of working and entrenched mindsets.
For those that can make it, though, the benefits in terms of accelerated business value will