<?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 for Continuous Delivery</title>
	<atom:link href="http://continuousdelivery.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://continuousdelivery.com</link>
	<description>Jez Humble&#039;s work blog</description>
	<lastBuildDate>Mon, 14 May 2012 04:50:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>Comment on Make Large Scale Changes Incrementally with Branch By Abstraction by [转载]什么是重构，什么不是重构 &#124; EmLinux</title>
		<link>http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/comment-page-1/#comment-2364</link>
		<dc:creator>[转载]什么是重构，什么不是重构 &#124; EmLinux</dc:creator>
		<pubDate>Mon, 14 May 2012 04:50:05 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=323#comment-2364</guid>
		<description>[...] “大规模重构”会变的很糟糕。你可能需要花数周、数月(甚至数年)才能完成，需要你对软件的很多部分进行改动。软件会因此不能运行，需要分多次发布这些变更，需要你做临时的台架(scaffolding)和变通方案——尤其是你采用短周期的敏捷开发方法时。这时Branch by Abstraction这样的实践方法就派上用场了，它能帮你在长周期内管理代码中的变化。 [...]</description>
		<content:encoded><![CDATA[<p>[...] “大规模重构”会变的很糟糕。你可能需要花数周、数月(甚至数年)才能完成，需要你对软件的很多部分进行改动。软件会因此不能运行，需要分多次发布这些变更，需要你做临时的台架(scaffolding)和变通方案——尤其是你采用短周期的敏捷开发方法时。这时Branch by Abstraction这样的实践方法就派上用场了，它能帮你在长周期内管理代码中的变化。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Make Large Scale Changes Incrementally with Branch By Abstraction by 什么是重构，什么不是重构 - 博客 - 伯乐在线</title>
		<link>http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/comment-page-1/#comment-2363</link>
		<dc:creator>什么是重构，什么不是重构 - 博客 - 伯乐在线</dc:creator>
		<pubDate>Mon, 14 May 2012 02:10:09 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=323#comment-2363</guid>
		<description>[...] “大规模重构”会变的很糟糕。你可能需要花数周、数月(甚至数年)才能完成，需要你对软件的很多部分进行改动。软件会因此不能运行，需要分多次发布这些变更，需要你做临时的台架(scaffolding)和变通方案——尤其是你采用短周期的敏捷开发方法时。这时Branch by Abstraction这样的实践方法就派上用场了，它能帮你在长周期内管理代码中的变化。 [...]</description>
		<content:encoded><![CDATA[<p>[...] “大规模重构”会变的很糟糕。你可能需要花数周、数月(甚至数年)才能完成，需要你对软件的很多部分进行改动。软件会因此不能运行，需要分多次发布这些变更，需要你做临时的台架(scaffolding)和变通方案——尤其是你采用短周期的敏捷开发方法时。这时Branch by Abstraction这样的实践方法就派上用场了，它能帮你在长周期内管理代码中的变化。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on On DVCS, continuous integration, and feature branches by Jez Humble</title>
		<link>http://continuousdelivery.com/2011/07/on-dvcs-continuous-integration-and-feature-branches/comment-page-1/#comment-2362</link>
		<dc:creator>Jez Humble</dc:creator>
		<pubDate>Wed, 09 May 2012 23:36:00 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=401#comment-2362</guid>
		<description>&gt; I tend to agree with them, since the software is often not in good condition.
This is the root cause of the problem. And of course your customers are responding rationally.

Over time, you need to move to a mainline development model, and require customers to upgrade in order to receive support. But for them to do that, you must first ensure that you fix the quality problems in mainline. Management has to ensure adequate resources are available to achieve this goal.

Once this is done, you can move most of your customers onto the mainline version, requiring them to do so in order to receive support. You&#039;ll probably have to keep some customers on older versions - but management will need to be courageous about who they allow to stay on old versions, and ensure they are always working to minimize the number of different versions being supported, with a goal of eventually moving everyone onto the mainline version.

One absolute rule has to be that features never get backported to older versions. Hopefully, if you continue to deliver valuable features, this will act as a &quot;carrot&quot; to convince people to upgrade.

HP had a similar problem with their firmware - you can read about how they moved to a mainline model in this book: http://www.amazon.com/dp/0321821726/</description>
		<content:encoded><![CDATA[<p>&gt; I tend to agree with them, since the software is often not in good condition.<br />
This is the root cause of the problem. And of course your customers are responding rationally.</p>
<p>Over time, you need to move to a mainline development model, and require customers to upgrade in order to receive support. But for them to do that, you must first ensure that you fix the quality problems in mainline. Management has to ensure adequate resources are available to achieve this goal.</p>
<p>Once this is done, you can move most of your customers onto the mainline version, requiring them to do so in order to receive support. You&#8217;ll probably have to keep some customers on older versions &#8211; but management will need to be courageous about who they allow to stay on old versions, and ensure they are always working to minimize the number of different versions being supported, with a goal of eventually moving everyone onto the mainline version.</p>
<p>One absolute rule has to be that features never get backported to older versions. Hopefully, if you continue to deliver valuable features, this will act as a &#8220;carrot&#8221; to convince people to upgrade.</p>
<p>HP had a similar problem with their firmware &#8211; you can read about how they moved to a mainline model in this book: http://www.amazon.com/dp/0321821726/</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Organize software delivery around outcomes, not roles: continuous delivery and cross-functional teams by Team, Player and Game Dimensions &#171; Slog Maverick</title>
		<link>http://continuousdelivery.com/2011/12/organize-software-delivery-around-outcomes-not-roles/comment-page-1/#comment-2361</link>
		<dc:creator>Team, Player and Game Dimensions &#171; Slog Maverick</dc:creator>
		<pubDate>Wed, 09 May 2012 15:18:02 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=485#comment-2361</guid>
		<description>[...] about let’s forget all that and just get something shipped today, sound [...]</description>
		<content:encoded><![CDATA[<p>[...] about let’s forget all that and just get something shipped today, sound [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on About by Facebook and the perpetual beta &#124; Amanda Belton</title>
		<link>http://continuousdelivery.com/about/comment-page-1/#comment-2357</link>
		<dc:creator>Facebook and the perpetual beta &#124; Amanda Belton</dc:creator>
		<pubDate>Mon, 30 Apr 2012 08:36:38 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?page_id=2#comment-2357</guid>
		<description>[...] in a Project Runway type of reality show &#8211; maybe next year we&#8217;ll be cool and hip? Could Jez Humble be a fabulous Tim Gunn type of mentor telling pairs to &#8216;make it work&#8217;? Share [...]</description>
		<content:encoded><![CDATA[<p>[...] in a Project Runway type of reality show &#8211; maybe next year we&#8217;ll be cool and hip? Could Jez Humble be a fabulous Tim Gunn type of mentor telling pairs to &#8216;make it work&#8217;? Share [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Continuous Delivery: The Value Proposition by Design and analysis occur at all points in the software lifecycle &#124; Mike Long</title>
		<link>http://continuousdelivery.com/2010/10/continuous-delivery-the-value-proposition/comment-page-1/#comment-2356</link>
		<dc:creator>Design and analysis occur at all points in the software lifecycle &#124; Mike Long</dc:creator>
		<pubDate>Mon, 30 Apr 2012 02:59:06 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=239#comment-2356</guid>
		<description>[...] In software development, the need to continuously deliver working software increases as companies engage customers in new and innovative ways. The organization must prioritize this capability as a core value in order to learn about customers and iterate rapidly. Sometimes we need to change direction in a more radical way if we discover what we&#8217;ve built isn&#8217;t valuable.[5] [...]</description>
		<content:encoded><![CDATA[<p>[...] In software development, the need to continuously deliver working software increases as companies engage customers in new and innovative ways. The organization must prioritize this capability as a core value in order to learn about customers and iterate rapidly. Sometimes we need to change direction in a more radical way if we discover what we&#8217;ve built isn&#8217;t valuable.[5] [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Continuous Delivery: The Value Proposition by Design and analysis occur at all points in the product lifecycle &#171; Mike Long</title>
		<link>http://continuousdelivery.com/2010/10/continuous-delivery-the-value-proposition/comment-page-1/#comment-2355</link>
		<dc:creator>Design and analysis occur at all points in the product lifecycle &#171; Mike Long</dc:creator>
		<pubDate>Sun, 29 Apr 2012 05:20:58 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=239#comment-2355</guid>
		<description>[...] In software development, the need to continuously deliver working software increases as companies engage customers in new and innovative ways. The organization must prioritize this capability as a core value in order to learn about customers and iterate rapidly. Sometimes we need to change direction in a more radical way if we discover what we&#8217;ve built isn&#8217;t valuable.[5] [...]</description>
		<content:encoded><![CDATA[<p>[...] In software development, the need to continuously deliver working software increases as companies engage customers in new and innovative ways. The organization must prioritize this capability as a core value in order to learn about customers and iterate rapidly. Sometimes we need to change direction in a more radical way if we discover what we&#8217;ve built isn&#8217;t valuable.[5] [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Continuous Delivery and ITIL: Change Management by Continuous Delivery and ITIL: Change Management &#124; ITIL Training Zone Blog from the Online ITIL Experts</title>
		<link>http://continuousdelivery.com/2010/11/continuous-delivery-and-itil-change-management/comment-page-1/#comment-2354</link>
		<dc:creator>Continuous Delivery and ITIL: Change Management &#124; ITIL Training Zone Blog from the Online ITIL Experts</dc:creator>
		<pubDate>Fri, 27 Apr 2012 09:10:29 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=243#comment-2354</guid>
		<description>[...] View original article&#8230;     /* [...]</description>
		<content:encoded><![CDATA[<p>[...] View original article&#8230;     /* [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Make Large Scale Changes Incrementally with Branch By Abstraction by What Refactoring Is and What It Isn&#8217;t &#124; Prasun&#8217;s Techblog</title>
		<link>http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/comment-page-1/#comment-2353</link>
		<dc:creator>What Refactoring Is and What It Isn&#8217;t &#124; Prasun&#8217;s Techblog</dc:creator>
		<pubDate>Sat, 21 Apr 2012 19:12:54 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=323#comment-2353</guid>
		<description>[...] like Branch by Abstraction (original entry of this technique) come in to play for these refactorings, to help you manage [...]</description>
		<content:encoded><![CDATA[<p>[...] like Branch by Abstraction (original entry of this technique) come in to play for these refactorings, to help you manage [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Continuous Delivery vs Continuous Deployment by Import Continuous Delivery &#8211; Part 1: Agile Processes taken to the Next Level &#124; zeroturnaround.com</title>
		<link>http://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/comment-page-1/#comment-2352</link>
		<dc:creator>Import Continuous Delivery &#8211; Part 1: Agile Processes taken to the Next Level &#124; zeroturnaround.com</dc:creator>
		<pubDate>Tue, 17 Apr 2012 14:51:27 +0000</pubDate>
		<guid isPermaLink="false">http://continuousdelivery.com/?p=138#comment-2352</guid>
		<description>[...] Over the last year or two, organizations with strong development teams have undergone something of a revolution. It really began in 2001 with the Agile Manifesto signalling the end of the waterfall methodology in software development, in favor of Agile tools and processes. These tools (Scrums, sprints, etc) have set the stage for what is turning out to be the ‘third renaissance’ in software development. “DevOps” &#8211; the merging of Development and Operations &#8211; viewing the entire delivery cycle of software as a single process, rather than the walled silos of old &#8211; is the stage for this new approach to application deployment: Continuous Delivery. (Read up for more understanding of Continuous Delivery vs. Continuous Deployment) [...]</description>
		<content:encoded><![CDATA[<p>[...] Over the last year or two, organizations with strong development teams have undergone something of a revolution. It really began in 2001 with the Agile Manifesto signalling the end of the waterfall methodology in software development, in favor of Agile tools and processes. These tools (Scrums, sprints, etc) have set the stage for what is turning out to be the ‘third renaissance’ in software development. “DevOps” &#8211; the merging of Development and Operations &#8211; viewing the entire delivery cycle of software as a single process, rather than the walled silos of old &#8211; is the stage for this new approach to application deployment: Continuous Delivery. (Read up for more understanding of Continuous Delivery vs. Continuous Deployment) [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

