Deploy Early and Often - Revision history

Sberczuk at 12:54, 13 July 2009

Sberczuk — Mon, 13 Jul 2009 12:54:12 GMT

←Older revision		Revision as of 12:54, 13 July 2009
Line 1:		Line 1:
-	Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a "release engineer" who take on the task as a "necessary evil." Reviews and demonstrations are done from a hand-crafted environment to ensure that everything works. The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes.	+	Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a release engineer who take on the task as a "necessary evil." Reviews and demonstrations are done from a hand-crafted environment to ensure that everything works. The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes.

	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. The deployed software is what the customer will use. By not ensuring that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly.		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. The deployed software is what the customer will use. By not ensuring that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly.

Kevlin at 21:51, 10 July 2009

Kevlin — Fri, 10 Jul 2009 21:51:11 GMT

←Older revision		Revision as of 21:51, 10 July 2009
Line 1:		Line 1:
-	Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a "release engineer" who take on the task as a "necessary evil." Reviews and demonstrations are done from a "hand crafted" environment to ensure that everything works The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes.	+	Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a "release engineer" who take on the task as a "necessary evil." Reviews and demonstrations are done from a hand-crafted environment to ensure that everything works. The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes.

-	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. The deployed software is what the customer will use~~, and by~~ not ~~making sure~~ that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly.	+	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. The deployed software is what the customer will use. By not ensuring that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly.

-	~~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.	+	Starting your project with an installation process will give you 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.		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: ~~experiement~~, evaluate, and refactor the deployment process as you go.	+	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 before 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: experiment, evaluate, 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 would with code~~. We test and refactor the source code throughout a project. The deployment deserves no less.	+	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. We test and refactor the source code throughout a project. The deployment deserves no less.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Sberczuk at 22:12, 16 February 2009

Sberczuk — Mon, 16 Feb 2009 22:12:53 GMT

←Older revision		Revision as of 22:12, 16 February 2009
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." ~~This~~ is the ~~wrong way~~ to ~~go about this~~.	+	Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a "release engineer" who take on the task as a "necessary evil." Reviews and demonstrations are done from a "hand crafted" environment to ensure that everything works The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes.

-	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.	+	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. The deployed software is what the customer will use, and by not making sure that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly.

	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.		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.
Line 7:		Line 7:
	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.		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~~.	+	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: experiement, evaluate, 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 would with code.	+	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 would with code. We test and refactor the source code throughout a project. The deployment deserves no less.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Kevlin at 16:48, 3 February 2009

Kevlin — Tue, 03 Feb 2009 16:48:36 GMT

←Older revision		Revision as of 16:48, 3 February 2009
Line 9:		Line 9:
	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.		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.	+	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 would with code.

	By [[Steve Berczuk]]		By [[Steve Berczuk]]

Kevlin at 16:47, 3 February 2009

Kevlin — Tue, 03 Feb 2009 16:47:08 GMT

←Older revision		Revision as of 16:47, 3 February 2009
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." This is the wrong way to do this.	+	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.		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 ~~you~~ project with an installation process, you have time to evolve ~~the~~ 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.	+	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 ~~was~~ 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 ~~best~~ to know all the trade-offs sooner rather than later.	+	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 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. This may sound like an "agile" approach, but it makes sense in every environment.	+	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.		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]]		By [[Steve Berczuk]]

Sberczuk at 23:02, 28 December 2008

Sberczuk — Sun, 28 Dec 2008 23:02:02 GMT

←Older revision		Revision as of 23:02, 28 December 2008
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 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 do this.

-	~~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/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.

-	~~Putting deployment last means that~~ the ~~deployment~~ process ~~may need~~ to ~~be more complicated~~ to ~~work around~~ assumptions in the code.	+	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 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.

-	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.	+	Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What was 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 best 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 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. 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.		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.

Sberczuk at 22:45, 27 December 2008

Sberczuk — Sat, 27 Dec 2008 22:45:02 GMT

←Older revision		Revision as of 22:45, 27 December 2008
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.
		+

Sberczuk: 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...

Sberczuk — Fri, 28 Nov 2008 22:40:14 GMT

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...

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 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.

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.

By [[Steve Berczuk]]

This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page