| I've used virtualenv extensively for production deployment in a large environment (100+ servers), with an environment very similar to yours. We developed on macs as well, and ran RHEL in production. All building/pushing to production was done from an RHEL similar to production. Some things that worked for us: - We deployed tarballs to production machines which unpacked to a single directory that included a virtualenv that had both all our code and all the modules we relied on, and anything else that the code needed to function that wasn't installed in a very basic RHEL install. - We used the --relocatable option in virtualenv to remove all references to absolute paths, which meant we could copy the virtualenv around to various directories and machines and still have it work. - We had a series of makefiles that would make/update a virtualenv, and which worked on both mac and linux. We would use this both in development and when deploying. For several packages, we had to hand tune this to work on both mac and linux, but for most things, it Just Worked. - When we deployed to production, we would unpack the tarball to a directory whose name included a version number for the push. We then had a symlink that pointed at the currently running version. This meant all we had to do to rollback a push was flip the symlink to the previous deployment directory, and restart. This rollback included any modules that changed (since they were in the virtualenv). I haven't seen any other way to reliably do this. The one thing you mention that we didn't have to deal with was mixed 32/64-bit environments. One nasty solution is to have two build machines, one 32-bit and one 64-bit, but there's probably a better way... |
Ah, we're doing tarballs too but only for our code. We're having pip munge the global package list at the beginning of every deployment (somewhat dicey but with requirements files its easy to rollback package upgrades/downgrades) which does mean that packages can change underneath a running Python process :O
- We used the --relocatable option in virtualenv to remove all references to absolute paths, which meant we could copy the virtualenv around to various directories and machines and still have it work.
Hmmm this could work, I was under the impression --relocatable wasn't fully tested but if its works for you, we'll definitely take a look at it :)
- We had a series of makefiles that would make/update a virtualenv, and which worked on both mac and linux. We would use this both in development and when deploying. For several packages, we had to hand tune this to work on both mac and linux, but for most things, it Just Worked.
Yeah I took at look at virtualenvwrapper to handle the multi-environment thing but that was primarily geared for multiple apps. Probably got me more confused than necessary. I'll take a look at plain old virtualenv wioth scripts.
- When we deployed to production, we would unpack the tarball to a directory whose name included a version number for the push. We then had a symlink that pointed at the currently running version. This meant all we had to do to rollback a push was flip the symlink to the previous deployment directory, and restart. This rollback included any modules that changed (since they were in the virtualenv). I haven't seen any other way to reliably do this.
We do the exact same thing, minus the modules. We do have an issue with packages changing underneath versions but if we don't bounce the servers they should have the "old" modules already imported. We should fix this though :)
The one thing you mention that we didn't have to deal with was mixed 32/64-bit environments. One nasty solution is to have two build machines, one 32-bit and one 64-bit, but there's probably a better way...
Yeah, our solution was to leave it to pip :)