This post originated from an RSS feed registered with Ruby Buzz
by Guy Naor.
Original Post: Managing Deployments of Plugins
Feed Title: Famundo - The Dev Blog
Feed URL: http://devblog.famundo.com/xml/rss/feed.xml
Feed Description: A blog describing the development and related technologies involved in creating famundo.com - a family management sytem written using Ruby On Rails and postgres
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.
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.
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.
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.
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.
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 svnmerge.py to make future backporting of fixes to the tagged release easy.
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.
Previous Topic
