Pragmatic Automation http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi Pragmatic Automation. Hosted by Mike Clark. en-us SwitchTower as an Automated Deployment Archetype http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Tools/SwitchTowerDeploymentArchetype.rdoc I&#8217;ve been remiss to have delayed mentioning <a href="http://manuals.rubyonrails.com/read/book/17">SwitchTower</a> until now. It&#8217;s an open-source utility that makes one-step deployment to one or more machines both possible and painless. <p> Say, for example, you need to roll out a new release of your killer app to two web servers, four application servers, and a database server. You could manually log in to each of those machines and type a list of commands, or just let SwitchTower do it for you: </p> <pre> rake deploy </pre> <p> That single incantation causes SwitchTower to execute the commands listed in your deployment recipe in parallel (and atomically) on multiple machines. (It uses <tt>ssh</tt> to communicate with the remote machines.) It&#8217;s really that easy. </p> <p> But then you notice that the application you just deployed has a bug. After giving your manager fifty push-ups, you&#8217;re thankful you can press the &quot;undo&quot; button: </p> <pre> rake rollback </pre> <p> That command rolls back the application to the last deployed version <em>on all deployed machines</em>. Yes, it&#8217;s really that easy. </p> <p> I&#8217;ve been starting to use SwitchTower on all my <a href="http://clarkware.com/rails.html">Rails projects</a>, and demo&#8217;ing it in our <a href="http://pragmaticstudio.com">Pragmatic Rails Studio</a>. As a result, SwitchTower has truly spoiled me. It&#8217;s an automator&#8217;s dream, and I can&#8217;t imagine going back to manual deployment gyrations. </p> <p> That brings us to the point of this elevator pitch: Can you deploy and roll back software releases this easily and consistently on your project? If not, I&#8217;d recommend you give the SwitchTower <a href="http://manuals.rubyonrails.com/read/book/17">manual</a> a read, especially if you <em>aren&#8217;t</em> building Rails applications. That&#8217;s right, even if you&#8217;ve never heard of Ruby or Rails you owe it to yourself to check out SwitchTower because its concepts aren&#8217;t specific to Ruby or Rails. And in fact it seems possible to use SwitchTower as the deployment vehicle for apps of any size and color by customizing a core set of tasks. I&#8217;d love to hear of efforts to adapt SwitchTower to J2EE projects, for example. </p> <p> Every software project can benefit from a deployment process that takes less time and money without sacrificing quality. SwitchTower is an archetype of automated deployment. Check it out before rolling your own solution. </p> When Build Silence Is Golden http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/BuildSilenceIsGolden.rdoc Andrew shared the following build frequency chart: <p> <img src="http://blogs.pragprog.com/images/pragauto/cewolf.png"> </p> <p> We see a flurry of good builds, then a six-day dry spell where almost no builds take place. Did somebody accidentally unplug the continuous build machine? Were all the developers at a conference? </p> <p> Perhaps there&#8217;s a better explanation when we remember that a build is only triggered when code is changed. In this case, no changes added up to good news for Andrew&#8217;s team: </p> <dl> <dt></dt><dd><em>We are particularly proud of the blank section as it signifies zero-defects on this in-production product ;-)</em> </dd> </dl> <p> Congrats! </p> CruiseControl 2.3.1 Released http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Tools/CruiseControl231.rdoc <a href="http://cruisecontrol.sourceforge.net">CruiseControl</a> 2.3.1 was released today with an enviable display of <a href="http://sourceforge.net/mailarchive/message.php?msg_id=13309089">nips and tucks</a>. <p> Get it <a href="http://cruisecontrol.sourceforge.net/download.html">here</a>. </p> Another Build Frequency Inkblot http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/AnotherBuildFrequencyInkblot.rdoc I&#8217;m glad to hear that someone else peeked under the CruiseControl metrics tab for a glimpse at their project&#8217;s build frequency. Here&#8217;s an interesting (colorful!) one from a reader who shall remain anonymous: <p> <img src="http://blogs.pragprog.com/images/pragauto/cccommitchart2.png"> </p> <p> Notice how different it is from the <a href="http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/WhatsYourBuildFrequency.rdoc">first team's chart</a>. For starters, the broken build frequency seems high, but at least they&#8217;re periodically getting back to a healthy state. I&#8217;d suggest they could do a bit more local testing before checking in code, or perhaps just get a bit more sleep. The person who submitted the chart included the following commentary: </p> <dl> <dt></dt><dd><em>We&#8217;re not so hip on the 40 hour work week; this activity is all from four people in the same office. Please don&#8217;t mistake that as bragging.</em> </dd> </dl> <p> What else do you see when you look at this chart? </p> What's Your Build Frequency, Kenneth? http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/WhatsYourBuildFrequency.rdoc In response to the <a href="http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/VisualizingCommitTrends.rdoc">source code activity charts</a>, Robert Watkins kindly sent in this example chart displayed free of charge in the <a href="http://cruisecontrol.sourceforge.net">CruiseControl</a> metrics tab. <p> <img src="http://blogs.pragprog.com/images/pragauto/cccommitchart.png"> </p> <p> It shows the frequency of builds which, of course, are triggered by commits to the source code repository. Looks like a slick way to also monitor trends in scheduled build breakage. What does your build frequency chart look like? </p> Visualizing Commit Trends http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/VisualizingCommitTrends.rdoc <a href="http://lemonodor.com/archives/001216.html">Take a peek</a> at these example charts of source code repository activity. What do they imply? I have no idea, but I find them fascinating. <p> I wonder what the charts would look like on a project where the team builds things in small chunks (where <em>small</em> means &quot;measured in minutes&quot;) and checks in code directly after each thing is built and tested. Or would that kind of predictable development rhythm just make the data less interesting? At any rate, it would be interesting to use a bit o&#8217; automation to keep a running chart from start to end of a project. </p> <p> Oh, and please be careful not to read too much into these charts. I shudder at the thought of some pointy-haired manager using them as input to an employee bonus formula. </p> CruiseControl 2.3 Released http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Tools/CruiseControl23.rdoc The dedicated team of folks who write code to keep your code continuously integrated have obviously been busy this summer. <a href="http://cruisecontrol.sourceforge.net">CruiseControl</a> 2.3 was released yesterday with a goodly amount of new features and plugins (<a href="http://sourceforge.net/mailarchive/message.php?msg_id=12776276">release notes</a>). <p> Get it <a href="http://cruisecontrol.sourceforge.net/download.html">here</a>. </p> Rake: Not Your Father's Build Language http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/RakeBuildLanguage.rdoc Martin Fowler has written an excellent <a href="http://martinfowler.com/articles/rake.html">article</a> describing the strengths of using <a href="http://rake.rubyforge.org/">Rake</a> as a build language, and how it compares to our old friends make and Ant. <p> Having used Rake extensively in recent months on a <a href="http://www.clarkware.com/cgi/blosxom/2005/08/18#VitalSourceStore">Rails project</a>, I can&#8217;t underscore enough how handy it is to have a full-blown language at your fingertips when crafting a build system. I got a taste of this power when I experimented with using Groovy to script Ant. I didn&#8217;t get a chance to push those boundaries before moving on to Rake, but it&#8217;s the same concept: build systems have much to gain from the use of an internal domain-specific language. </p> <p> A must read! </p> Is Your Build Agile? http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/AgileBuilds.rdoc SD Times just posted a <a href="http://www.sdtimes.com/article/special-20050815-01.html">new article</a> concerning lengthy builds siphoning energy off agile processes. <p> I think we&#8217;ll continue to see the tools and processes of old getting in the way of the rapid feedback required to move quickly and confidently. It&#8217;s an opportunity to revisit the value of those tools and processes, and adjust accordingly. </p> Yes, We're Control Freaks http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/General/RepeatableApplications.rdoc I didn&#8217;t realize how much automation we have in and around our <a href="http://rubyonrails.com">Rails</a> project until the other day when our shared development server took a vacation and never came back. It&#8217;s like that backup strategy that only gets tested when the hard drive fails. Except in this case it was pretty much a yawner. Once we decided to go to a new machine, we were up and running in no time. There were no panic-stricken fire drills. For all intents and purposes, it was business as usual. <p> Part of the credit for no downtime goes to the fact that we all work untethered on our local machines. (This turns out to be super handy on long airplane rides.) This forces a discipline of keeping things relatively self contained. But we do hook up to the mother ship often (or right after those plane rides) to synchronize our work in a shared Subversion repository. The contents of that repository represent life. On demand, we can recreate anything in the repository&#8212;any version of a file from the time the project started up to the present. Everything else is out of our control. </p> <p> The key to repeatability lies in how much stuff you put in version control. It&#8217;s best just to go long. On our project, <a href="http://blog.x180.net">James</a> meticulously made sure that our Rails application was as self contained as possible. Using only the Subversion repository as a source, our entire application and its supporting infrastructure can be built from scratch. We regularly put that to the test on our local machines, and the development server is just another machine. </p> <p> It&#8217;s relatively easy to automate small things, but it&#8217;s especially rewarding when those recipes are applied to automate the big things, as well. Indeed, for large projects, no single recipe will do. But in his latest <a href="http://blog.x180.net/2005/07/rails_sandbox_d.html">blog</a>, James discusses some strategies that you might be able to pick up and apply to your project. </p> Firefox Plugin for CruiseControl http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/CCFirefoxPlugin.rdoc Inspired by the recent <a href="http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/CCWidget.rdoc">Dashboard widget</a>, Dmitri Maximovich wrote a <a href="http://www.md.pp.ru/mozilla/cc/">Firefox plugin</a> to monitor builds in CruiseControl. He&#8217;s looking for your feedback to help make it even better&#8230; CruiseControl Widget http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/CCWidget.rdoc The <a href="http://www.apple.com/macosx/features/dashboard/">Dashboard</a> in Tiger is an ideal way to monitor automation at work with just a glance. I&#8217;ve been anxiously awaiting word of attractive widgets that monitor builds and running programs. <p> Jason Sypher and Mark Husson came through with style today by unveiling the <a href="http://rubicore.com/code/cruisecontrol/">CruiseControl Widget</a>. Check out the <a href="http://rubicore.com/code/cruisecontrol/">screenshots</a>. Yum! </p> Rapid Feedback http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Deploy/RapidFeedback.rdoc <a href="http://x180.net">James Duncan Davidson</a> and I are building a Rails application for a client. We needed a way to synchronize the code in the Subversion repository with the code being run on the shared test server. That way, everyone on the team could benefit from rapid feedback. <p> Time for a little automation. So James cooked up a Subversion post-commit script which I&#8217;ve posted on my <a href="http://www.clarkware.com/cgi/blosxom/2005/05/22#RapidFeedback">blog</a>. </p> Project Dependencies Using Ant http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Build/AntDependencies.rdoc <a href="http://www.exubero.com/">Joe Schmetzer</a> has posted a short and sweet <a href="http://www.exubero.com/ant/dependencies.html">article</a> on how he uses Ant target dependencies and the &lt;import&gt; task to manage the build order of sub-projects. Examples scripts are there for the taking. Autonomation http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/General/Autonomation.rdoc <a href="http://fun3d.larc.nasa.gov">Bil Kleb</a> wrote in to share an insightful term described in Taiichi Ohno&#8217;s book <em>Toyoto Production System: Beyond Large-Scale Production</em>: <dl> <dt></dt><dd>The Toyota production system utilizes <em>autonomation</em>, or automation with a human touch, rather than automation. Autonomation means transferring human intelligence to a machine. The concept originated with the auto-activated loom of Toyoda Sakichi. His invention was equipped with a device that automatically and immediately stopped the machine if the vertical or lateral threads broke or ran out. In other words, a device capable of making a judgment was built into the machine. <p> At Toyota, this concept is applied not only to the machinery but also to the production line and the workers. In other words, if an abnormal situation arises, a worker is required to stop the line. Autonomation prevents the production of defective products, eliminates overproduction, and automatically stops abnormalities on the production line allowing the situation to be investigated. </p> </dd> </dl> <p> What sorts of autonomation does your project have to &quot;stop the machine&quot; before abnormalities compound? </p>