<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/stylesheets/rss.css" type="text/css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>The Dev Blog: Managing Deployments of Plugins</title>
    <link>http://devblog.famundo.com/articles/2007/01/24/managing-deployments-of-plugins</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>Putting Family Management on Rails!</description>
    <item>
      <title>Managing Deployments of Plugins</title>
      <description>&lt;p&gt;I find the rails plugins to be a really good concept. I'm yet to write an application without plugins. But plugins present a problem for deployment. &lt;/p&gt;

&lt;p&gt;Using the plugins installed into the application directory is not DRY when I use the same plugin in more than one application, especially if I want to make sure I use a specific release I tested and know to be good, or if I add some changes to the code.&lt;/p&gt;

&lt;p&gt;Using it as external from the plugin repository is risky in more than one way. No way to know for sure that I am using a stable (that I tested!) code, and raises the issue of my deployment being dependent on the remote server being up when I deploy. Adding one more thing not under my control to the release process. In addition, there's no way to know that I'm always releasing with exaclty the same code base, as I might get a different plugin version when I deploy it in the future.&lt;/p&gt;

&lt;p&gt;I use a solution that merges the advantages of both options above, while eliminitating the problems they cause. I keep my own version of the plugins in my svn repository, and I point my externals to that repository. This way what I checkout is always something I know I tested to be working, while still not duplicating code changes all over the place.&lt;/p&gt;

&lt;p&gt;The last part of this strategy is release tagging. Each release I put out to the production servers is tagged in svn. But this raise a problem with the externals. They will always point to the latest and again risk instability when I upgrade/change the plugins code. To solve this, I wrote a script that does the tagging, and tags the plugins as well as the main application. This way every tagged release is stable and will always include the correct code I intended it to use.&lt;/p&gt;

&lt;p&gt;As an added bonus, the script does the same tagging to the rails code used in the application from vendor/rails. This way the rails code is stable for the release as well. And also uses &lt;a href="http://www.orcaware.com/svn/wiki/Svnmerge.py"&gt;svnmerge.py&lt;/a&gt; to make future backporting of fixes to the tagged release easy. &lt;/p&gt;

&lt;p&gt;The script is customized to my setup and so I'm not posting it here, but if you are interested, let me know and I might post a more generalized form of the script, or give you some pointers on how to write your own version of the script.&lt;/p&gt;</description>
      <pubDate>Wed, 24 Jan 2007 13:09:00 -0500</pubDate>
      <guid isPermaLink="false">urn:uuid:1ae115d8-f339-4ca2-9c51-6e15a89214b3</guid>
      <author>guy.naor@famundo.com (Guy Naor)</author>
      <link>http://devblog.famundo.com/articles/2007/01/24/managing-deployments-of-plugins</link>
      <category>Rails</category>
    </item>
  </channel>
</rss>
