我是一个团队的成员，该团队将发布一个基于python(特定于Django)的网站的beta版本以及随附的后端工具套件。在过去的几周中，团队本身的规模已从2倍增加到4倍，我们预计至少在接下来的几个月中会持续增长。一个已经困扰我们的问题是，在配置他们的开发环境和安装所有合适的鸡蛋等方面，使每个人都快上一步。

我正在寻找简化此过程并减少出错的方法。 zc.buildout和virtualenv看起来都将是解决此问题的好工具，但两者似乎都主要集中在特定于python的问题上。我们有几个其他语言的小子项目(特别是Java和Ruby)，还有许多必须本地编译的python扩展(lxml，MySQL驱动程序等)。实际上，我们方面最大的棘手问题之一就是针对共享库的相应版本来编译其中的一些扩展，以避免出现段错误，malloc错误和各种类似问题。在4个人中有4个不同的开发环境没有帮助，在ppc上有-1豹，在intel上有1豹，有1个ubuntu和1个窗口。

最终，理想的情况是在dos / unix提示符下大致像这样工作：

$ git clone [存储库URL]
...
$ python setup-env.py
...

然后执行zc.buildout / virtualenv的工作(复制/符号链接python解释器，提供一个干净的空间来安装egg)，然后安装所有必需的egg，包括安装任何本机共享库依赖项，安装ruby项目，java项目等。

显然，这对于建立开发环境以及在登台/生产服务器上进行部署都是有用的。

理想情况下，我希望通过python以/可扩展的方式实现此目的的工具，因为那是(并将永远是)我们团队的通用语言，但是我愿意接受其他语言的解决方案。

因此，我的问题是：是否有人对使用更好的替代方案有任何建议，或者可以使用其中一种解决方案来分享更大/更广泛的安装基础而分享的经验？

解决方案

基本上，我们正在寻找跨平台的软件/软件包安装程序(在apt-get / yum / etc上)。我不确定是否存在类似的东西？

另一种选择是指定需要通过特定于操作系统的软件包管理系统(例如Mac OS X的Fink或者DarwinPorts)安装的软件包列表，并使用脚本来设置内部代码的构建环境？

自发布问题以来，我一直在研究此问题。看来有人在尝试解决我概述的一些需求，例如Minitage和Puppet采取了不同的方法，但是都可以实现我想要的功能-尽管Minitage没有明确声明它支持Windows。缺少任何更好的选择，我将尝试使zc.buildout可以作为其中之一，或者只是广泛地自定义使用以满足我们的需求，但是我仍然觉得必须有更好的选择。

我们可能会考虑使用正在运行的任何生产OS以及所有预先构建的软件依赖项来创建虚拟机设备。可以远程或者使用共享文件夹编辑代码。在具有相当复杂的开发环境的前世中，它对我来说非常有效。

Puppet也(不容易)支持Win32世界。如果我们正在寻找一种部署机制而不仅仅是"开发者设置"工具，则可以考虑研究具有开源跨平台解决方案的ControlTier(http://open.controltier.com/)。

不仅限于此，我们还需要使用诸如BladeLogic或者OpsWare之类的"企业"软件，而且对于所提供的功能，通常价格太高了(很明显，我认为)。

许多人一直在积极地使用Puppet和Capistrano的组合(甚至是非Rails开发人员)来部署自动化工具，以达到很好的效果。不利的一面再次是，它期望一个稍微均一的环境。

Setuptools可能提供的功能比我们想像的还要多-例如，如果我们需要lxml的自定义版本才能在MacOS X上正常工作，则可以在setup.py和让setuptools根据需要在开发人员的环境中下载并安装该工具；还可以告诉它从版本控制中下载并安装依赖项的特定版本。

就是说，我倾向于使用脚本生成的虚拟环境。构建一个kickstart文件非常简单，该文件可以安装我们依赖的任何程序包，然后针对该文件启动虚拟机(或者生产硬件！)，使用puppet或者类似软件进行其他管理(添加用户，设置服务[数据库来自哪里) ？]， 等等)。当生产环境包括多台计算机时，这特别方便-只需编写脚本即可在其方便的小沙盒子网中生成多个VM(我为此使用libvirt + kvm；虽然kvm并非在所有开发人员都在使用的平台上可用，qemu肯定是，或者我们可以像我一样做，并拥有由多个开发人员共享的少量强大的VM主机)。

这使我们摆脱了支持N个平台的麻烦-我们仅支持一个虚拟平台-意味着部署过程(由kickstart文件和用于设置的人偶代码定义)是源代码控制的，并且贯穿我们质量检查和审核流程与其他所有流程一样。

我总是在项目的顶层创建一个" develop.py"文件，并且还有一个" packages"目录，其中包含我要安装的PyPI的所有" .tar.gz"文件，并且还包括一个未打包的文件准备从该文件直接运行的virtualenv的副本。所有这些都进入了版本控制。每个开发人员都可以简单地检查出主干，运行develop.py，不久之后，便可以使用虚拟环境了，其中包括我们所有依赖项的版本完全与其他开发人员使用的版本相同。即使PyPI发生故障，它也可以正常工作，这在该服务的历史记录中非常有用。