StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POHelp me improve my continuous deployment workflow
text
Body
copied!<p><strong>I've been developing a workflow for practicing a mostly automated <a href="http://www.startuplessonslearned.com/2009/02/work-in-small-batches.html" rel="noreferrer">continuous deployment</a> cycle for a PHP project.</strong> I'd like some feedback on possible process or technical bottlenecks in this workflow, suggestions for improvement, and ideas for how to better automate and increase the ease-of-use for my team.</p> <hr> <h2><strong>Core components</strong>:</h2> <ul> <li><a href="http://wiki.hudson-ci.org/display/HUDSON/Home" rel="noreferrer"><code>Hudson</code></a> CI server</li> <li><code>Git</code> and <a href="http://www.github.com" rel="noreferrer"><code>GitHub</code></a></li> <li><a href="http://www.phpunit.de/" rel="noreferrer"><code>PHPUnit</code></a> unit tests</li> <li><a href="http://seleniumhq.org/projects/remote-control/" rel="noreferrer"><code>Selenium RC</code></a></li> <li><a href="http://saucelabs.com/how-it-works" rel="noreferrer"><code>Sauce OnDemand</code></a> for automated, cross-browser, cloud testing with <code>Selenium RC</code></li> <li><a href="http://www.puppetlabs.com/puppet/introduction/" rel="noreferrer"><code>Puppet</code></a> for automating test server deployments</li> <li><a href="http://code.google.com/p/gerrit/" rel="noreferrer"><code>Gerrit</code></a> for Git code review</li> <li><a href="http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Trigger" rel="noreferrer"><code>Gerrit Trigger</code></a> for <code>Hudson</code></li> </ul> <hr> <p><strong>EDIT</strong>: I've changed the workflow graphic to take ircmaxwell's contributions into account by: removing <code>PHPUnit</code>'s extension for <code>Selenium RC</code> and running those tests only as part of the QC stage; adding a QC stage; moving UI testing after code review but before merges; moving merges after the QC stage; moving deployment after the merge.</p> <p>This workflow graphic describes the process. My questions / thoughts / concerns follow.</p> <p><img src="https://i.stack.imgur.com/M2WIQ.png" alt="Continuous Deployment Workflow"></p> <h2><strong>My concerns / thoughts / questions</strong>:</h2> <ul> <li><p>Overall difficulty using this system.</p></li> <li><p>Time involvement.</p></li> <li><p>Difficulty employing <code>Gerrit</code>.</p></li> <li><p>Difficulty employing <code>Puppet</code>.</p></li> <li><p>We'll be deploying on <code>Amazon EC2</code> instances later. If we're going about setting up <code>Debian</code> packages with <code>Puppet</code> and deploying to <code>Linode</code> slices now, is there a potential for a working deployment on <code>Linode</code> to break on <code>EC2</code>? Should we instead be doing our builds and deployments on <code>EC2</code> from the get-go?</p></li> <li><p>Another question re: <code>EC2</code> and <code>Puppet</code>. We're also considering using Scalr as a solution. Would it make as much sense to avoid the overhead of <code>Puppet</code> for this alone and invest in Scalr instead? I have a secondary (ha!) concern here about cost; the <code>Selenium</code> tests shouldn't be running <strong><em>that</em></strong> often that <code>EC2</code> build instances will be running 24/7, but for something like a five-minute build, paying for an hour of <code>EC2</code> usage seems a bit much.</p></li> <li><p>Possible process bottlenecks on merges.</p></li> <li><p>Could "A" be moved?</p></li> </ul> <p><strong>Credits</strong>: Portions of this workflow are <a href="http://about.digg.com/blog/continuous-deployment-code-review-and-pre-tested-commits-digg4" rel="noreferrer">inspired by Digg's awesome post on continuous deployment</a>. The workflow graphic above is <a href="http://source.android.com/source/life-of-a-patch.html" rel="noreferrer">inspired by the Android OS Project</a>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload