Deploy Early and Often

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: Deployment and Installation processes are often put off til close to the end of a project. In some projects writing installation tools is delegated to a "release" person who take on the t...)
Line 1: Line 1:
-
 
+
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.
-
Deployment and Installation processes are often put off til 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.
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.
-
The installation process is essential to the productivity of your customers (or your professional serices team) so you should be testing and refacting this process as you go, much as you treat code.
+
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.
 +
 

Revision as of 22:45, 27 December 2008

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.


By Steve Berczuk

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools