Don't Touch that Code! - Revision history

Kevlin: Don't touch that code! moved to Don't Touch that Code!

Kevlin — Fri, 10 Jul 2009 21:17:26 GMT

Don't touch that code! moved to Don't Touch that Code!

←Older revision

Revision as of 21:17, 10 July 2009

Kevlin at 21:17, 10 July 2009

Kevlin — Fri, 10 Jul 2009 21:17:15 GMT

←Older revision		Revision as of 21:17, 10 July 2009
Line 1:		Line 1:
-	It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is "~~quick~~, let me fix that, I know what's wrong."	+	It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is "Quick, let me fix that — I know what's wrong."

	In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server.		In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server.
Line 10:		Line 10:
	* Production server		* Production server

-	Yes, there are other servers and services sprinkled in there, like source code control and ticketing, but you get the idea. Using this model, a developer, even a senior developer, should never have access beyond the development server. Most development is done on a developer's local machine using their favorite blend of IDEs, virtual machines, and an appropriate amount of black magic sprinkled over it for good luck.	+	Yes, there are other servers and services sprinkled in there, like source code control and ticketing, but you get the idea. Using this model, a developer — even a senior developer — should never have access beyond the development server. Most development is done on a developer's local machine using their favorite blend of IDEs, virtual machines, and an appropriate amount of black magic sprinkled over it for good luck.

-	Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.	+	Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on, though, the developer is a spectator to the process.

	The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for acceptance testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.		The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for acceptance testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.

Calevans at 15:42, 18 December 2008

Calevans — Thu, 18 Dec 2008 15:42:13 GMT

←Older revision		Revision as of 15:42, 18 December 2008
Line 14:		Line 14:
	Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.		Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.

-	The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for ~~system~~ testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.	+	The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for acceptance testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.

	Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone ''cough''me''cough'' violated this last rule. If it's broke, production is not the place to fix it.		Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone ''cough''me''cough'' violated this last rule. If it's broke, production is not the place to fix it.

Calevans at 15:31, 18 December 2008

Calevans — Thu, 18 Dec 2008 15:31:02 GMT

←Older revision		Revision as of 15:31, 18 December 2008
Line 5:		Line 5:
	In most web-based development environments the architecture can be broken down like this:		In most web-based development environments the architecture can be broken down like this:

-	* Local development on the developer's machine	+	* Local development and unit testing on the developer's machine
	* Development server where manual or automated integration testing is done		* Development server where manual or automated integration testing is done
	* Staging server where the QA team and the users do acceptance testing		* Staging server where the QA team and the users do acceptance testing

Kevlin at 04:30, 18 December 2008

Kevlin — Thu, 18 Dec 2008 04:30:27 GMT

←Older revision		Revision as of 04:30, 18 December 2008
Line 17:		Line 17:

	Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone ''cough''me''cough'' violated this last rule. If it's broke, production is not the place to fix it.		Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone ''cough''me''cough'' violated this last rule. If it's broke, production is not the place to fix it.
		+
		+	by [[Cal Evans]]
		+
		+	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

Kevlin at 04:29, 18 December 2008

Kevlin — Thu, 18 Dec 2008 04:29:44 GMT

←Older revision		Revision as of 04:29, 18 December 2008
Line 1:		Line 1:
-	It has happened to ~~all~~ of us at some point~~; your~~ code was rolled on to the staging server for testing and the testing manager writes back that she has hit a problem. Your first reaction is "quick, let me fix that, I know what's ~~wrong”~~.	+	It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is "quick, let me fix that, I know what's wrong."

-	In the bigger sense though, what is wrong is that as a developer you think you should have access to the staging server.	+	In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server.

-	In most web based development environments the architecture can be broken down like this:	+	In most web-based development environments the architecture can be broken down like this:

-	* Local development on the ~~developer’s~~ machine	+	* Local development on the developer's machine
	* Development server where manual or automated integration testing is done		* Development server where manual or automated integration testing is done
	* Staging server where the QA team and the users do acceptance testing		* Staging server where the QA team and the users do acceptance testing
-	* Production server.	+	* Production server
		+
		+	Yes, there are other servers and services sprinkled in there, like source code control and ticketing, but you get the idea. Using this model, a developer, even a senior developer, should never have access beyond the development server. Most development is done on a developer's local machine using their favorite blend of IDEs, virtual machines, and an appropriate amount of black magic sprinkled over it for good luck.

-	Yes, there are other servers and services sprinkled in there like Source Code Control and Ticketing, but you get the idea. Using this model, a developer, even a senior developer, should never have access beyond the development server. Most development is done on the developer’s local machine using their favorite blend of IDEs, virtual machines and an appropriate amount of black magic sprinkled over it for good luck.
	Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.		Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.

-	The staging manager should package and roll the code to the staging server for the QA team.Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If ~~it’s~~ ready for testing, cut a release and roll, ~~don’t~~ ask the user to ~~“Just~~ look at something real ~~quick”~~ on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.	+	The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for system testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.

-	Under no circumstances, ever, at all, should a developer have access to a production server. If there is a problem, your support staff should either fix it, or request that you fix it~~, check~~ it into SCC ~~and then~~ they will roll a patch from there. Some of the biggest programming disasters ~~I’ve~~ been a part of have taken place because someone coughmecough violated this last rule. If ~~it’s~~ broke, production is not the place to fix it.	+	Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone ''cough''me''cough'' violated this last rule. If it's broke, production is not the place to fix it.

Calevans at 12:25, 17 December 2008

Calevans — Wed, 17 Dec 2008 12:25:47 GMT

←Older revision		Revision as of 12:25, 17 December 2008
Line 1:		Line 1:
-	~~Developers~~ should ~~never~~ have access to ~~production servers, not even~~ staging servers. ~~They~~ should ~~also~~ never ~~test~~ their ~~own~~ code.	+	It has happened to all of us at some point; your code was rolled on to the staging server for testing and the testing manager writes back that she has hit a problem. Your first reaction is "quick, let me fix that, I know what's wrong”.
		+
		+	In the bigger sense though, what is wrong is that as a developer you think you should have access to the staging server.
		+
		+	In most web based development environments the architecture can be broken down like this:
		+
		+	* Local development on the developer’s machine
		+	* Development server where manual or automated integration testing is done
		+	* Staging server where the QA team and the users do acceptance testing
		+	* Production server.
		+
		+	Yes, there are other servers and services sprinkled in there like Source Code Control and Ticketing, but you get the idea. Using this model, a developer, even a senior developer, should never have access beyond the development server. Most development is done on the developer’s local machine using their favorite blend of IDEs, virtual machines and an appropriate amount of black magic sprinkled over it for good luck.
		+	Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on though, the developer is a spectator to the process.
		+
		+	The staging manager should package and roll the code to the staging server for the QA team.Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it’s ready for testing, cut a release and roll, don’t ask the user to “Just look at something real quick” on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both.
		+
		+	Under no circumstances, ever, at all, should a developer have access to a production server. If there is a problem, your support staff should either fix it, or request that you fix it, check it into SCC and then they will roll a patch from there. Some of the biggest programming disasters I’ve been a part of have taken place because someone coughmecough violated this last rule. If it’s broke, production is not the place to fix it.

Calevans: New page: Developers should never have access to production servers, not even staging servers. They should also never test their own code.

Calevans — Wed, 17 Dec 2008 11:32:08 GMT

New page: Developers should never have access to production servers, not even staging servers. They should also never test their own code.

New page

Developers should never have access to production servers, not even staging servers. They should also never test their own code.