<story><title>Continuous Deployment </title><url>http://www.avc.com/a_vc/2011/02/continuous-deployment.html</url></story><parent_chain><item><author>fleaflicker</author><text>&lt;i&gt;I asked how to roll back the changes. He said &quot;we don&apos;t roll back, we fix the code.&quot;&lt;/i&gt;&lt;p&gt;Not the best idea. I don&apos;t debug as well under the extreme pressure of my site being broken with the clock ticking.</text></item></parent_chain><comment><author>neilk</author><text>It&apos;s not always like that. John Allspaw&apos;s answer is correct in the sense that actual rollbacks aren&apos;t done -- the fix will be a new push -- but sometimes, before you do that, you will just turn the new feature off in production.&lt;p&gt;This is possible because many new behaviour is controlled by &quot;feature flags&quot; which are associated with the server configuration. So you have the benefit of everybody, developers and production, staying very close to trunk, but still being able to have radically different behavior on development machines versus production.&lt;p&gt;That said, I have participated in debugging sessions on a product which used continuous deployment, and they can indeed be nerve-wracking. Personally I wouldn&apos;t want to use CD by itself, without a good culture of code review and a great test suite.</text></comment>
<story><title>Continuous Deployment </title><url>http://www.avc.com/a_vc/2011/02/continuous-deployment.html</url></story><parent_chain><item><author>fleaflicker</author><text>&lt;i&gt;I asked how to roll back the changes. He said &quot;we don&apos;t roll back, we fix the code.&quot;&lt;/i&gt;&lt;p&gt;Not the best idea. I don&apos;t debug as well under the extreme pressure of my site being broken with the clock ticking.</text></item></parent_chain><comment><author>bdotdub</author><text>When you know you can&apos;t really rollback, I&apos;m sure you&apos;re helluva lot more sure that your code won&apos;t take down the site</text></comment>