惭愧，UTCOM已经上线半年多了，这半年，我几乎没有怎么改善它。原因很多很复杂，幸好不是丧失热情的原因。

所以，最近我开始又抽时间在UTCOM上，着重改善其部署和规范方面，以适应未来的快速变化。

之前我在回顧 2009年之“UTCOM：從開發到運維”中写到过，UTCOM是用Django开发的，虽然暂时只是小小的一个网站，但是充分利用了Django的Plugable机制（也就是Projectless），细分了很多模块：Appcenter，Sourcecenter，它们都是独立的存在的，以App的形式插在UTCOM这个Project里。

此外，在源码控制级别，我应用的是Git+Submodule，平常，当我的模块有更新时，我只需要“git submodule update”一下，就可以顺利更新。部署十分方便。

但是经过半年的运作，这个方式有些缺陷：

• Git submodule固然方便，然而这对目录的安排有比较严格的限制，这也使得App无法弄成可以用python setup tools来安装的形式，变成了“UTCOM Only”，没有独立App可自由分发的特点；
• Git submodule不够灵活，我无法方便地来指定某个提交，某个branch；
• 之前的部署有点死板，与系统的依赖性较高，当前用的是Django 1.1，如果想用Django 1.2，就需要动很多东西
• ……

如果用截图来描述，大概是这样：

appcenter是UTCOM的其中一个应用，它的源码树目录就直接是文件。

它与UTCOM的Project目录是平级的，都放在PYTHONPATH能找到的路径，然后开始直接运作。

既然找到了这些缺点，该如何克服呢？这时，我学习了这篇文章：http://www.clemesha.org/blog/2009/jul/05/modern-python-hacker-tools-virtualenv-fabric-pip/

通过virtualenv，fabric和pip这三个工具，让部署、分发真正方便和自由。其中：

virtualenv和pip

这两个工具是打包在一块的，通过virtualenv提供一个独立运作的Python应用环境，里面所有的module和app都与系统自带不冲突，因此不管系统的是Django 1.0，还是Django 1.1，你都可以无障碍地使用上任一版本的Django——甚至是系统没有的。

此刻该环境还有一个叫pip的工具，它是一个取代easy_install的工具，pip是非常强大的：支持uninstall，支持下载特性保证全部能安装，还支持从git等源码直接获取进行安装。

Fabric

fabric则是一个自动化工具，它可以完成任意可以由脚本完成的事情，非常适合在本地操作远程——你不需要一次又一次的SSH到远程再进行部署。

了解以后，我发现要用virtualenv和pip，首先要将我之前的所有App都转化为标准的Python软件包，也就是基于setuptools。这个好办了，毕竟之前搞Ubuntu Tweak的打包也是用这招的。

然后稍微模拟了一下，未来的部署环境的样子已经出来了，大概是这样：

新的appcenter目录里，不再是直接可以import进来用的了。多了setup.py、MANIFEST.in等文件，这使得我可以用“python setup.py install”来将我的app安装在任意环境里。也就是pip将通过这个方式来安装这个app。

而UTCOM的项目呢？嗯，整个都变成了一个Python根分区了：里面有独立的bin/python，有独立的lib/python2.6，不会与系统本身的干扰。

而utcom的项目目录，此刻也简洁了不少，其他app不是一鼓脑儿地装在utcom目录下了，它们将以标准的python模块，被安装至lib/python2.6目录下。

再以后，我将用一个简单的txt来控制app与UTCOM的版本对应关系（解决版本、分支等对应关系），在本地用“fab deploy”一条命令（自定义脚本，方便部署），就可以告诉远程的机器用pip去升级或更新UTCOM下面的app。真正把virtualenv、pip和fabric完美地结合在一块。

此外，因为我其他的app都已经做成了标准的、可分发的Python模块，以后我若需要在新的项目中复用它，也是非常顺其自然的事情。

现在我只是模拟了这一状况，接下来在真正部署的过程中，才能真正证明这套方式是不是真的经得起考验！