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." The installation process is the first thing that the customer sees, and a simple installation process is the first step to having a reliable (or at least easy to debug) production environment.
By starting you project with an installation process, you have time to evolve the the process as you move through the product development cycle, and the change 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.
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 to until you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do in 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.
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