<?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"
	>
<channel>
	<title>Comments on: Automating the build&#160;pipeline</title>
	<atom:link href="http://www.magpiebrain.com/blog/2005/01/10/automating-the-build-pipeline/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.magpiebrain.com/blog/2005/01/10/automating-the-build-pipeline/</link>
	<description>Sam Newman's blog</description>
	<pubDate>Fri, 08 Aug 2008 19:09:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Sam Newman</title>
		<link>http://www.magpiebrain.com/blog/2005/01/10/automating-the-build-pipeline/#comment-615</link>
		<dc:creator>Sam Newman</dc:creator>
		<pubDate>Tue, 11 Jan 2005 16:01:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.magpiebrain.com/2005/01/10/automating-the-build-pipeline/#comment-615</guid>
		<description>Yes, which is the point I was trying to make. A proper, full build pipeline can extend at least as far as producing an artifact that the business are happy to deploy directly - it may even extend to carrying out the deployment itself. Any system used to manage such a pipeline must allow parts of the pipeline to be manual - in effect the pipeline blocks waiting on human input. I've used the example of QA sign-off before - the business might require that a QA examine and accept the changes before proceeding, in which case your build pipeline system might have a task which raises an issue in Jira asking for signoff, and blocks until it's resolved one way or another.
</description>
		<content:encoded><![CDATA[<p>Yes, which is the point I was trying to make. A proper, full build pipeline can extend at least as far as producing an artifact that the business are happy to deploy directly &#8211; it may even extend to carrying out the deployment itself. Any system used to manage such a pipeline must allow parts of the pipeline to be manual &#8211; in effect the pipeline blocks waiting on human input. I&#8217;ve used the example of QA sign-off before &#8211; the business might require that a QA examine and accept the changes before proceeding, in which case your build pipeline system might have a task which raises an issue in Jira asking for signoff, and blocks until it&#8217;s resolved one way or another.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: B. K. Oxley (binkley)</title>
		<link>http://www.magpiebrain.com/blog/2005/01/10/automating-the-build-pipeline/#comment-614</link>
		<dc:creator>B. K. Oxley (binkley)</dc:creator>
		<pubDate>Tue, 11 Jan 2005 15:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.magpiebrain.com/2005/01/10/automating-the-build-pipeline/#comment-614</guid>
		<description>Very nice diagram.  I appreciate your point about automated v. manual artifacts, and am loathe to give up on full automation.  However, the latter tests you present are, by definition, manual as they are the chance for actual human input into using the final artifacts (if I understand your diagram correctly).</description>
		<content:encoded><![CDATA[<p>Very nice diagram.  I appreciate your point about automated v. manual artifacts, and am loathe to give up on full automation.  However, the latter tests you present are, by definition, manual as they are the chance for actual human input into using the final artifacts (if I understand your diagram correctly).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
