Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Everything Automatically Deployed
Tools are available today to deploy custom software using silent installers, and most packages can be deployed automatically and configured as well. (If a package can't be installed silently, you really need to ask your vendor why!) Similarly, databases, database schemas, and even test data can be created via automated scripts. Of course, this isn't always practical (think about multi-terabyte databases), so you may have to assume a starting condition of some QA or development versions of these artifacts being present. But the goal should be to do as much setup as possible automatically, and assume the least amount of preconditions.
Nobody would say that production deployment should just occur automatically when a developer makes a change to the source code. QA still has an important role in doing exploratory testing on any release, exercising the system in ways that none of the automated tests would generally expect. As well, there are all sorts of reasons for gates on change—some regulatory, others just common sense (for instance, don't update the e-commerce system on the Friday after Thanksgiving).
However, once things pass QA and user acceptance testing, the process of moving from QA to pre-production to production should be automatic, except for invoking the script to start the process. Once you have this kind of process in place, continuous integration with automated regression testing and deployment, and a staff that embraces the process, you're well on your way! From here, you can move on to integration of quality metrics into the build process.