One of the only persons who comment here is Grig Gheorghiu. Recently, he had a couple posts regarding the setuptools module for Python (here and here). While I think setuptools is interesting from an opensource project deployment method, it is definitely overkill for deployments in a commercial test environment.

I can deploy our full automated testing environment in under 5 minutes on any of our supported platforms with just one command — ‘p4 sync’. This also allows me to easily propagate any changes to all machines just as easily.

Of course, getting to this level of deploy ability certainly has a bit of front-loaded work…

Lets say for the sake of argument, your testing area in whatever VCS you are using (you are using one, right?) looks something like this


bin/
   testrunner.py
lib/
   support_lib_01.py
   support_lib_02.py
scripts/
   <nice structure as per the guidelines <a href="?p=21">here</a>>

The first thing you need to do is add a couple directories…


storage/
   <all your original installers/tarballs go here for archive purposes>
platform/
   platform_01
   platform_02
   platform_n
(platform in this case is a unique identifier for an OS (solaris, linux64 etc))

To save time, omit this from all your clients when deploying. These are only needed when building out your platforms (next)

The next step is the most time consuming; especially if you need to build something like python-ldap which has a billion dependencies. What you need to do is compile everything and install it using platform_n as your install root. Any by everything I mean everything your testing requires including python (if your tests are written in python that is), but not libraries that are part of the system by default. You should end up with something like this


platform/
   platform_n/
      bin/
         python
      lib/
         python2.4/
            lib/
               site-packages/
                  etc...

This whole structure needs to be added to VCS. To save time when deploying, omit the platforms from your client that are not related to the deployment target.

Finally, what you need to do is create a wrapper for your testrunner.py to set the environment correctly to work with your new little sandbox. One thing that will make your life easier is making everything relative to the root of all theses directories. This wrapper then calls your main test launcher. The wrapper I use (on the unixes) can be seen here.

From there it’s a couple hours figuring out all the path and package dependencies you forgot were built into your tests. Then you get to do it for all your supported platforms. As I mentioned, its a fair bit of work initially, but I think its worth it since

  • you can turn any machine into a properly deployed testing machine in a matter of minutes
  • you have absolute control over the environment
  • you are (less likely) to run into version specific bugs on different platforms as you have the same version across all platforms
  • if you rev a version of a module you are using or patch something then you do not have to rebuild and redeploy; just sync with VCS
  • anyone can deploy the environment
  • does not require root/sudo permissions