On Wed, May 06, 2009 at 08:12:30AM -0700, Tim wrote: > I am working on a Django project which has gotten to the point > where I need some sanity and repeatability in deployment. My > first instinct was to just start building things from scratch > with shell scripts and to manage db migrations with one-off sql > scripts. But then I started thinking that there's got to be a > better way. What is the current state of deployment frameworks - > not necessarily specific to Django but Django-firendly?
For GNU/Linux systems, I suggest you consider using one of the package management systems that are already used to deploy tens of thousands of applications, including all your system software. State of the art in this area are RPM and dpkg. RPM [1] is mostly used by Red Hat and derivatives, and dpkg [2] is mostly used by Debian and derivatives. I use Debian (and to a lesser degree, Ubuntu), so the obvious choice for me is dpkg. Information about packaging Web applications for it is relatively scant. I suspect this is due to the fact that Web developers have a tendency to expect to take a single hierarchy containing application code, configuration, and user data, and simply drop it in the Web server's doc root. That's simple, and it allows for installation on systems where superuser access is not available, but the entanglement makes upgrades complicated (how to preserve config and user data across upgrades?), creates security problems (software installed in a place that's writable by the Web server -- yikes) and it does not allow for conformance to the Filesystem Hierarchy Standard [3]. [1]: <http://www.rpm.org/> [2]: <http://www.debian.org/doc/FAQ/ch-pkgtools.en.html> [3]: <http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard> I haven't used it yet, but Debian's dbconfig-common [4] purports to implement some "best practices for database applications" [5], by facilitating the creation of packages which will: * support mysql, postgresql and sqlite based applications * create databases and database users * access local or remote databases * upgrade/modify databases when upstream changes database structure * remove databases and database users * generate config files in many formats with the database info * import configs from packages previously managing databases on their own * prompt users with a set of normalized, pre-translated questions * handle failures gracefully, with an option to retry. * do all the hard work automatically * work for package maintainers with little effort on their part * work for local admins with little effort on their part * comply with an agreed upon set of standards for behavior * do absolutely nothing if it is the whim of the local admin * perform all operations from within the standard flow of debian package maintenance (no additional skill is required of the local admin) I'm presently in the midst of learning to package Django applications using debhelper [6]. Baurzhan Ismagulov published some helpful notes about packaging Django projects for Debian using Autotools [7], including an introduction that explains why one might wish to package a Django app in the first place. [4]: <http://people.debian.org/~seanius/policy/dbconfig-common-using.html/> [5]: <http://people.debian.org/~seanius/policy/dbapp-policy.html/> [6]: <http://en.wikipedia.org/wiki/Debhelper> [7]: <http://www.radix50.net/~ibr/notes/20080323-0-django-autotools-debian.html> Egg [8] seems to be a popular cross-platform way of packaging Python applications for distribution, but then you have software that is outside the control of your package management system, creating various risks and complications. Virtualenv [9] can be used to install all Python dependencies for a particular application in one hierarchy. I'm not familiar with it, and wonder how one handles security-related (or otherwise urgent) upgrades of various dependencies when myriad versions of them are sprinkled throughout various virtual environments. I don't know how people do consistent and reliable systems administration without a good package management system. When I quit paying attention to it years ago, Windows had no such thing, and people tended to simply re-install the whole OS and all applications periodically because of the mess that developed. I don't know if that has changed, but I suspect not. Mac OS X has some concept of packages, but as far as I know, it doesn't handle things like dependency resolution (possibly because Mac apps bundle all their dependencies with each app; not sure; this is not my area of expertise) and installation from a central package repository. Also note that dpkg has been ported to OS X as part of the Fink Project [10]. [8]: <http://peak.telecommunity.com/DevCenter/PythonEggs> [9]: <http://pypi.python.org/pypi/virtualenv> [10]: <http://www.finkproject.org/> -- Phil Mocek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
