项目实践

我的最近的一个项目中，客户想要我们在4周之内搭建出一个原型出来，通过这个原型，客户想要看到一些业务场景在可以通过Web化的方式来实现（之前是一个单机版的应用）。这个项目的挑战在于搭建原型的时间很短，我们需要做一些取舍：比如哪些实践是必须的，哪些不是。

虽然有一些压力，但是我们还是坚持了自己的想法。一开始就搭建了CI环境，甚至有了自动部署到测试环境的构建任务，开发的每一次提交都会触发一次自动部署。

项目开始还算顺利，在第迭代1的第二周，我在调试一个异步的组件：这个组件从消息队列得到通知，然后解压用户上传的文件，紧接着调用另外一个服务做一些数据转换，最后再将转换过的数据保存到数据库。我们很快的为这个组件创建了新的版本库，新的CI构建，以及新的自动化部署脚本。

由于本地的开发环境是Windows，我们很难模拟一套完整的系统（该死的Windows下的路径名），所以我们决定在一个Linux机器上做测试。有自动化部署这套机制的保证，我们可以非常快速的进行系统的集成测试：消息的生产者发送消息给队列服务器，队列再分发到我们的组件上。

有一天下午，有人在服务器上修改了用户权限（好吧，那个人就是我了），然后所有的自动化部署都失败了（由于ssh的鉴权问题），团队里的其他人不得不手工的进行部署：本地提交代码之后，等CI服务器运行完所有测试之后，开发者手工的触发一次部署命令，同时输入密码。

本来我想着这个过程不会那么频繁，但是事实上它比我想象的要频繁的多。本地修改几行代码，commit一次，手工部署，测试，发现问题，再来一次。在我崩溃前，另一个同事也终于受不了了，他登录到服务器上，修改了ssh配置文件的权限，一切又恢复了正常。

这个故事除了证明“恶心的事情频繁做”这个原则之外，也说明了一个持续集成，持续发布的机制是多么重要。即使是在开发环境、开发场景中也是如此。

想想你可以让一个新特性在10分钟内上线是一种什么样的体验！