Deploy Early and Often
Deployment and installation processes are often put off until close to the end of a project. In some projects writing installation tools is delegated to a "release" person who take on the task as a "necessary evil." This is the wrong way to go about this.
The installation/deployment process is the first thing that the customer sees, and a simple installation/deployment process is the first step to having a reliable (or at least easy to debug) production environment.
By starting your project with an installation process, you have time to evolve the process as you move through the product development cycle, and the chance to make changes to the application code to make the installation easier. Running and testing the installation process on a clean environment periodically also provides a check that you have not made assumptions in the code that rely on the development or test environments.
Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What seemed a great idea in an IDE, where you have full control over an environment, might make for a much more complicated deployment process. It is better to know all the trade-offs sooner rather than later.
While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the reality is that until you can demonstrate you application on the target environment, there is a lot of work to do until you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway, since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: make your best guesses, and refactor the deployment process as you go. This may sound like an "agile" approach, but it makes sense in every environment.
The installation/deployment process is essential to the productivity of your customers (or your professional services team) so you should be testing and refactoring this process as you go, much as you treat code.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page