<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: deployment schedules are not effective</title>
	<atom:link href="http://www.effectivedevelopment.net/2009/04/deploy-schedules-do-not-work/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.effectivedevelopment.net/2009/04/deploy-schedules-do-not-work/</link>
	<description>Thoughts from the World Of Practical Web Development</description>
	<lastBuildDate>Tue, 13 Jul 2010 13:22:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Kevin B</title>
		<link>http://www.effectivedevelopment.net/2009/04/deploy-schedules-do-not-work/comment-page-1/#comment-2</link>
		<dc:creator>Kevin B</dc:creator>
		<pubDate>Thu, 02 Apr 2009 22:40:42 +0000</pubDate>
		<guid isPermaLink="false">http://effectivedevelopment.wordpress.com/?p=22#comment-2</guid>
		<description>Another drawback to deploying code on a release schedule is that problems with one module can trigger a rollback that affects all the components in the release. You quickly learn that the more elements you daisy chain together, the higher your chances of failure.

Release schedules work much better for traditional shrink-wrapped software than for the internet. Point releases are far superior for internet development, in my opinion.

Problems arise when you have different groups handling code deployment and infrastructure monitoring. Wake your systems guy up a couple of times at 3am with a web server or DB locked up from newly deployed bad code and you will find yourself looking at a more rigid format for deploying code. Also at a clearly defined rollback procedure....  Read More

Personally, I am a fan having the same team code, deploy and monitor, but this is not possible in large organizations.</description>
		<content:encoded><![CDATA[<p>Another drawback to deploying code on a release schedule is that problems with one module can trigger a rollback that affects all the components in the release. You quickly learn that the more elements you daisy chain together, the higher your chances of failure.</p>
<p>Release schedules work much better for traditional shrink-wrapped software than for the internet. Point releases are far superior for internet development, in my opinion.</p>
<p>Problems arise when you have different groups handling code deployment and infrastructure monitoring. Wake your systems guy up a couple of times at 3am with a web server or DB locked up from newly deployed bad code and you will find yourself looking at a more rigid format for deploying code. Also at a clearly defined rollback procedure&#8230;.  Read More</p>
<p>Personally, I am a fan having the same team code, deploy and monitor, but this is not possible in large organizations.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
