想年轻时，自动化一切并乐此不疲，直到我碰见了Cruise的部署问题。
大家都知道，Cruise采取的是Smart Server + Dummy Agent的架构，每个Server可以对应N个Agent, 开发是一件乐事，然而部署不是。 每次发布，大家都得小心翼翼的
ssh到Server上用apt-get升级，
根据环境下载.exe, osx.zip或者.deb
scp安装包到相应的agent
ssh到每一台agent，升级agent
嘿，有事情不对劲儿了，不是么？ 你看什么了？ 手工过程，很多邪恶的手工过程，自动化才是王道！
但是，请等一下…..
为什么要去手工下载安装包更新Agent？
因为安装文件是按照不同平台打包的，放在独立的下载站点上，由于Agent可能访问不了外网，它无法自行去下载站点下载安装文件。
既然Cruise Agent知道Cruise Server在哪儿，为什么不把Cruise Agent的安装文件放在Cruise Server上？
你是说我们要把所有的Agent安装包放在Cruise Server上？ 这样占太多空间了。
为什么不能只提供一个jar包呢？ 它是Java应用，只需要一个jar，不是么？
嗯….？？！！
为什么需要脚本重启它？
Agent是一个Java进程，它不能把自己杀死再重启。所以必须有另外的脚本安装更新后再重启。
原来问题的关键不是自动化部署，而是：
1. Agent得不到新版本的安装包。
解决方案: agent.jar放在Server上，用MD5一比就知道有没有更新了
2. Agent无法把自动重启。
解决方案：写一个很薄的bootstrapper层，用它启动/重启agent
搞定，我们作了什么？ 我们并没有解决部署问题，我们解决了一个架构问题，或者说是设计问题，而部署问题不治自愈。
我相信这是Kent在Responsive Design Worhshop试图表达的观点之一： 设计者决不能停留在问题的表面，在带上技术专家的帽子激情满怀的解决问题之前，停下来，问5次为什么？ 不要被幻象蒙蔽了眼睛。因为
这也许不是配置问题，而是设计问题
这也许不是性能问题，而是设计问题
这也许不是部署问题，而是设计问题
….