持续集成之“Everything is code”(2)

　　“嗨，Joe。这里的 script 目录里面放什么的呢?” Jared 问道。

　　“哦，这个目录是放所有我们用到的脚本的。” Alex 笑着说，“以前大家在测试、部署等工作中写了很多脚本，用在各自的工作中。现在我们统一放在这个目录中，这样所有人都可以使用相同的脚本做相同的事情。比如，当开发人员在自己调试时，只要执行部署脚本 autodeploy，它就会从开发配置目录 (conf/dev)中读取相关配置，部署好开发调试环境。而测试人员使用同一个部署脚本 autodeploy，它就会从测试配置目录(conf/test)目录中读取相关配置，部署好测试环境，生产环境部署也运行同一个脚本，只不过说生产环境配置而已。”

　　“这样不错。我们的脚本在最终向生产环境部署之前就已经被测试过很多次啦。” Jared 笑道。

　　四、数据也是代码吗?

　　“我们有点跑题了，回到我们最开始遇到的那个测试问题上吧。” Jared 说，“那个测试失败，除了功能的小改动以外，log 里还有一些异常，好象是数据格式问题。”

　　“嗯，这部分测试用到的数据放在一个固定的共享目录中了。可是，虽然文件名没有变化，但其中的数据格式已经改了。也就是说，这份测试代码与测试数据存在不一致性。” Joe 说道。

　　Alex 接道，“嗯，我们现在把数据也放到了代码仓库中。”

　　Jared 一脸狐疑，问道：“数据那么大，怎么放到代码仓库中呢?SVN 保存大数据并不高效，而且占用空间也比较大呀。”

　　“Alex 只说了完了一半。其实，我们是把大数据放在了一个我们自行开发的版本控制系统中了。当把一份大数据放在其上时，该系统会返回唯一的一个标识 ID，我们把它放在了这个产品代码的 conf 目录中。这样，当签出某个版本的代码时，你就可以直接拿到对应的大数据了。如果大数据修改了，那只要把它再次放到那个大数据存储系统中，然后把返回的唯一标识更新到对就应的 conf 目录中就行了。”Joe 补充道。“如果没有这样一个大数据库版本管理系统，也可以使用共享目录，只不过，每个子目录下保存一份数据，把这个子目录地址放在 SVN 里，也就行了。”

　　“对于数据库结构的修改，我们还有另外一种方法，就是利用类似于 DBmaintain 或是 DBDeploy 这样的工具。把每一次数据库结构的变更都写到一个数据库脚本，并把它们和代码放到一起。这样，升级过程就由这些工具就完成了。”

　　五、Everything is code

　　“哦，我明白了。”Jared 说道，“就是围绕我们的服务或产品，将所有的东西进行版本管理。这样，所有的内容都只有唯一的一个源，所有人都可以拿到同样的信息，而且自动化工作也非常容易了。”

　　“是的。而且，当完成这一步以后，所有的事情自然都成为可跟踪可追溯的了。”Joe 笑道：“这也算是一个额外的收益吧。”

原文转自：http://kb.cnblogs.com/page/127846/