Continuous Delivery : A Mini Hurdle

The first hurdle to overcome with Continuous Delivery I think is not getting your product’s code onto the machine itself, but managing the actual machine and it’s software… and in talking to people. It is the subtle nuances between machines due to people tweaking things on the fly that lead to the worst [most annoying] bugs to troubleshoot.
The end-goal of managing your machines is that no one ever logs into the machine directly.

Database Integration – some points to keep in mind

Always Have a Single, Authoritative Source For Your Schema
Everyone should know where the official schema resides, and have a frictionless experience in getting a fresh database setup. One should be able to walk up to a computer, get the latest from source control, build, and run a simple tool to setup the database (in many scenarios, the build process can even setup a database if none exists, so the process is one step shorter).

Always Version Your Database
The common goal is to propagate changes from development, to test, and ultimately to production in a controlled and consistent manner. A second goal is to have the ability to recreate a database at any point in time. This second goal is particularly important if you are shipping software to clients. If someone finds a bug in build 20100612.1 of your application, you must be able to recreate the application as it appeared in that build – database and all.

One Perspective on Improved Software Quality and Reduced Risks

We talk endlessly about improved software quality and reduced risks, but deployable software is the most tangible asset to “outsiders”
such as clients or users. The importance of this point cannot be overstated.