<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Passing Curiosity: Posts tagged continuous deployment</title>
    <link href="https://passingcuriosity.com/tags/continuous-deployment/continuous-deployment.xml" rel="self" />
    <link href="https://passingcuriosity.com" />
    <id>https://passingcuriosity.com/tags/continuous-deployment/continuous-deployment.xml</id>
    <author>
        <name>Thomas Sutton</name>
        
        <email>me@thomas-sutton.id.au</email>
        
    </author>
    <updated>2012-08-19T00:00:00Z</updated>
    <entry>
    <title>PyconAU 2012: Continuous Deployment</title>
    <link href="https://passingcuriosity.com/2012/continuous-deployment/" />
    <id>https://passingcuriosity.com/2012/continuous-deployment/</id>
    <published>2012-08-19T00:00:00Z</published>
    <updated>2012-08-19T00:00:00Z</updated>
    <summary type="html"><![CDATA[<p>Continuous deployment. The same thing as continuous delivery for our purposes
here.</p>
<blockquote>
<p>Being able to deploy every good version of your software.</p>
</blockquote>
<p>More than technology: techniology for automation, people, environment.</p>
<p>Fail fast, win fast; competitive advantage; real-time control; pivoting, etc.</p>
<p>Have a single path to production; optimising for resilience. “If it hurts, do
it more often.” Automate as much as possible.</p>
<ul>
<li>Use vagrant to develop on as close to live as possible.</li>
<li>Develop, test, commit.</li>
<li>Run a build: unit tests, static analysis, coverage. Very fast.</li>
<li>Iff: functional tests, integration tests.</li>
<li>Iff: deploy to staging, test migration, smoke and UI tests.</li>
<li>Iff: you can push the deploy button.</li>
<li>Then: goes to production.</li>
<li>Users are happy.</li>
<li>Measure, monitor, analyse.</li>
<li>Learn from the information and feedback into the loop.</li>
</ul>
<h3 id="environments">Environments</h3>
<p>Make all environments look the same, minimising differences minimises
surprises. Use <code>vagrant</code> to provision virtual boxes (configured in similar
ways to staging and live environments).</p>
<p>Having a repeatable, versioned configuration. Use Puppet, Chef, shell scripts,
whatever. Just use <em>something</em>.</p>
<p>“Snowflake” servers (every one precious and unique) are bad, “phoenix” servers
are the goal.</p>
<p>Use Puppet for provisions and OS and services; Fabric for scripted tasks.</p>
<p>Use virtualenv and pip. Make all your configuration as code.</p>
<p>Use South for schema and data migrations. Split your expansion and contraction
columns: only drop the old columns after everything is working correctly in
production.</p>
<h3 id="testing">Testing</h3>
<p>Using Django’s testing framework, driven by Jenkins. There’s a django-jenkins
plugin.</p>
<p>Use <code>factory_boy</code> to generate testing data.</p>
<p>Test separation: don’t run slow or flaky tests every build.</p>
<h3 id="build">Build</h3>
<p>One way to build and deploy; all developers fit into the same process. Make
“don’t deploy broken code” easier;</p>
<h3 id="deploy">Deploy</h3>
<ul>
<li>django-dbbackup</li>
<li>pull()</li>
<li>apply_puppet()</li>
<li>django-extensions</li>
<li>syncdb</li>
<li>collectstatic</li>
</ul>
<p>Use feature flags. <a href="https://github.com/disqus/gargoyle/">Gargoyle</a> or
<a href="https://github.com/jsocol/django-waffle/">Waffle</a> in Django.</p>
<h3 id="monitor">Monitor</h3>
<ul>
<li>Errors go into <a href="http://sentry.readthedocs.org">Sentry</a>.</li>
<li>Munin</li>
<li>NewRelic</li>
<li><a href="http://django-statsd.readthedocs.org/">django-statsd</a></li>
</ul>
<h3 id="rollback">Rollback</h3>
<p>Having some way to recover from bad or failed builds.</p>]]></summary>
</entry>

</feed>
