Configuration management for non-Java apps
Patrick Peak seemed to have misinterpreted no deployment means for a Rails app. I’m certain that we’re talking about “no deployment” during development. Compared to *some* Java environments, it is a big win to be able to just try something and refresh the page. However, especially for folks doing test-driven development, I think this is definitely not the biggest win from Rails.
In Java, it is pretty well standardized that folks bundle up a war file, which they then toss onto their production app server at the right time. Patrick points out that you can change JSPs and even .java files on some app servers, if you wish. But, people certainly don’t do that on production servers.
And the same is true of anyone who’s been doing software for a while, regardless of language. You only need to be bitten once to learn that having a solid production deployment plan and tools is critical.
James Duncan Davidson describes exactly how he deploys Rails apps: Rails: Sandbox, Develop, and Deploy. For anyone who hasn’t been bitten by a bad change on a production server, I’d recommend reading that. He describes a very solid way of going from rapid development to trouble-free deployment.
From Patrick’s article, regarding deployment of a Rails app:
Developers deploy to a testing or production by manually zipping up the project and copying to the server. (Since there is no Ant to do it for you). Anything I’m missing here?
The answer is “yes”. What Patrick is missing is that Perl, Python and Ruby are all excellent “scripting languages” (some are more excellent than others, but I won’t go there…) I know firsthand that moving files around to get just the right subset and zipping up those files is a nice, short script in Python thanks to modules like shutil and zipfile.
My process for Zesty News is similar to what James talks about in his article. Getting a new machine up and running to do development on Zesty News is easy:
1. Install Subversion
2. Check out the project
3. Install a few pre-reqs (Python 2.4.1 primarily. On Windows, there are a couple other things needed to get a sane build environment. That will go away before too long, though.) All of the pre-reqs are right there in the project.
4. In the top directory of the project, python build.py modules. This builds additional components used by Zesty News.
5. At this point, the unit tests and the app are ready to run.
To create an executable, I just run “python build.py app”.
There are all kinds of things that need to happen to pull all of the pieces together. There’s no way I would do that stuff by hand. My “build.py” script and the various commands for it are one of the first things that I did. It’s not a lot of code, and I really don’t miss ant.
Just using agile languages does not imply a lack of good configuration management.
On Web-SIG (a little on distutils-sig too) we’re working on what I think will be a pretty nice deployment system with Eggs and WSGI. Basically you’ll make every application a distutil package, and add some configuration to indicate where the WSGI app is in your package. And everything is versioned.
Then deployment means installation (easy_install — which can pull from an index, including internal indexes, or from a specific location), and then some configuration of the server side (which is inevitable — you have to say what application goes where, and indicate additional configuration that’s specific to your installation).
There are some important problems that I think this will handle. Like how to run multiple applications in a single process without conflict (very useful if you are supporting very small apps), how to handle a single host where different app servers are running different versions of the same application, and good conventions for where things go and a sort of Best Practices. I’m feeling quite optimistic about it.