本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Putting Absolutely Everything in Version Control"一文。

持续交付(Continuous Delivery)的一个关键原则就是将所有东西都放入版本控制系统中。这解决了一些重大问题，但也引入了一些其他问题。

持续交付是持续集成(CI)的一个自然扩展。后者旨在每次代码签入后运行构建并为开发者提供即时的反馈，而持续交付的目标则涵盖更广。它谋求在每 次代码签入后进行构建、测试以及最终可执行程序的部署（这里的部署针对的是测试环境，而不是生产环境）。这个想法保证了一个工程在任何时候都拥有 一个已知部署安全的可交付的应用。这个应用也许不是功能完备的，但却是可以运行起来的。

在一些拥抱敏捷开发的地方，持续交付正逐渐追上了持续集成的脚步，因为它在许多领域促进了最佳实践的使用，并消除了在部署过程中发现意外缺陷的问 题。它还使得团队熟知部署，让依靠传统手段进行部署所带来的那令人屏息的时刻成为历史。

把所有东西都放入版本控制系统(Version Control System, VCS)是对持续交付很重要的一个最佳实践。是所有东西，我说的的确是所有东西。这里引用一段对持续交付有着重要意义的文字：“当然，开发者应该使用版本 控制系统管理源码，但是也应该将其用于测试、数据库脚本、构建和部署脚本、文档、库以及你的应用的配置、你的编译 器和工具集等等。这样一个刚进入团队的新成员便可以从头开始工作了”。

这是一种激进的状态 — 我们中有多少人会把编译器放入版本控制系统中呢？但是，它解决了一个重要的问题：重建旧版本的软件，虽然这种情况很少见，但一旦出现，可能会给你带来很大困难。大 多数从事过编程维护工作的人都有无法重现一个缺陷的经验，因为任意一个工具的改变都会导致原先的二进制程序无法被复制出来。这种方法还给我们提供 了另外一个好处：可以保证每个团队成员在开发中使用相同的文档和工具。无需再担心海外的团队成员获取到不同的需求或使用一个更新版本的编译器等问 题了。团队中的每个人都是从同一口井里取水的。

然而，完成这一任务并非易事。最近在波士顿举行的Citcon(译者注：CITCON, the Continuous Integration and Testing Conference)上，这个话题就在一个CI爱好者的会议上被提出讨论。第一个问题是许多开发工具不只是一个简单的二进制程序和一些动态库，相反，他 们依赖OS库并且必须安装后才能正确的运行起来（尤其是在Windows上）。这个问题在某种程度上可以通过使用虚拟机来补救。在虚拟机上安装OS以及用 于自动化构建的工具，接下来将整个虚拟机签入到版本控制系统中。这种方式工作起来很好，不过它也需要你在虚拟机中构建你的产品，否则你需要建立两套独立的 环境，他们难免会不同步。（Linux和Unix受这个问题影响较小，因为它们没有注册表。上帝请保佑那些将二进制文件和配置文件放在同一个目录下的产品 的工具制造者吧！）

一个更隐蔽的问题是并不是所有的版本控制系统都能很好地支持二进制文件。例如，Git被设计成一个纯粹的SCM（而不是VCS， 译注：SCM，Software Configuration Management，软件配置管理系统），在处理规模较大的工程或具有大量二进制文件的工程时十分困难。（如果你将工具和虚拟机签入，从SCM角度来 说，你的项目将自动变大）。在这个领域，商业产品更加擅长。尤其是Perforce，它在快速处理二进制文件，尤其是大工程上面下了大量功夫。

另一个挑战是脚本中存在的密码。持续交付中的部署针对的是非生产环境，将密码留在非生产环境（即测试环境）下风险可能很小，这可部分抵消这个问题的影响面。对其它组织而言，对密码进行加密是可以提供的另外一个解决方案。

最后，我应该注意到即便上面提到的那本书（译注：指的是《持续交付》这本书）也是不推荐将构建产生的二进制文件放入VCS中的，这是有道理的。毕竟二进制 文件很大并且样式繁多。而将所有东西都放入VCS的重点只是为了能够在未来的某个时间点上重建出那些相同的二进制文件。

就个人而言，我不认为可能将每个项目的所有东西都放入SCM中。基于Linux的使用开源工具的工程最有希望达成这一目标。然而，我相信为了尽可能地接近 这个目标而付出的努力是值得的。它赋予你一种安全感：可以在任一时刻，回到过去重建旧版本的产品，并且所有人都基于同一个工具源上工作。在我看来，这些益 处要远大于其他原则引入的弊端。

自我认知是循序渐进的，体会到了，就想将其整理出来，给自己一个交代。
                                                                            - Tony Bai

关于我的工作原则，感觉之前的那篇总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。

* 重塑标准

简单来说就是根据组织实际情况，重新建立各种标准 – 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。

* 问题理解要透彻

很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。

* “眼见为实”还不够

俗语讲：眼见为实。但在工作中，有些时候“眼见为实”还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的“事实”。要追求逻辑的全局合理性，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。

* 把事情做在前面

以推进知识管理为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。