今天是一个特别值得纪念的日子 – 我和老婆的结婚五周年纪念日。五年前的今天我和老婆领了证，正式步入了围城。平时总被她抱怨不浪漫的我这次特意准备了一对黄金玫瑰耳钉作为我们“木婚” （结婚五年）纪念日的礼物。老婆也蛮喜欢，我也甚是Happy（以前LP总是不中意我给她买的礼物）。

很想对这五年来的婚姻生活做一次“精彩”的回顾，但想了许久，也不得思路。于是我发现这几年的婚姻生活和大多数家庭一样 – 温馨而平淡，没什么“惊天动地”的故事。我和老婆也都是那种不善于表达的人类，尤其是情感方面，没有那么多细腻的东西，有些不那么浪漫。婚后的生活也无非 是衣食住行+柴米油盐+适当的娱乐。

和大多数现代年轻家庭一样，老婆在家里是名义上的“一把手”：老婆指东，我决不向西，但实际上一些大事还是我拿主意^_^。老婆在家里属于绝对的“享乐型”，除了女儿的一些事情外，一切大小事务基本都全权交给我处理，用句俗话说：LP不是操心的命儿啊。

在家里，老婆手握财政大权，这几年来总体感觉钱管得还可以，至少知道钱没有乱花，她就是传说中的能存住钱的主儿。我们的家庭也遵循着中国社会俗的不能再俗的现实版家庭成长路线 – 房子、孩子、车子、房子(for daughter)…

家庭生活中，两个人不可避免会有些磕磕碰碰。每次红脸，老婆总是坚持到最后的那个胜利者。

老婆爱逛街，我就陪她去香港逛；老婆爱看青春都市剧，如果是我觉得还不错的，我就让陪着老婆看，并端上洗好的水果，有些时候帮她打打洗脚水^_^。

老婆爱减肥，给她买呼拉圈，“怂恿”她去晨跑，监督她晚上不吃饭。结果呼拉圈上早已落了一层灰，我也基本养成了晨跑的习惯，而她的体重似乎没有明显变化。

老婆工作忙，加班较多，每天下班都去接她，有时候在外面等到很晚。后来老婆心疼我：干脆让我坐班车，她自己开车。

老婆不是那么“求上进”，于是我总唠叨她去学习去提高，并给她买了一些可以帮助她在工作中提升技能的书。书在书架上沉睡了好长时间后，终于在最近得到了老婆的垂青。老婆在学到新知识、新技能后，也是很有成就感的，还主动在我面前“炫耀”。我暗自窃喜：我的目的达到了。

老婆对我要求倒甚是严格。总是拿我与他们公司的这个副总、那个总的比来比去，让我倍感亚历山大，于是我就持续奋发图强，希望在不久在将来能有更好的结果让老婆满意。

老婆认准的事情（虽然不多），她总是努力去办到。比如当年老婆就是坚持自己生果果，坚决不剖，于是每天晚饭后，我都陪着挺着大肚子的LP在小区溜弯至少一 小时，即便是数九寒冬；再比如老婆坚持母乳喂养。在奶水不足，上班不便的情况下，也楞是让果果吃了一年的母乳。这点我还是挺佩服的。

掐指算来：每天早上6：30起床，7：30出门，晚上18：30回家，22：30以后入睡。不算睡眠时间，实际一个工作日与lp在一起的时间也就是5-6个小时。有时候一天也说不上几句话。

婚姻生活就是这样的平淡入水，但是只要两个人活得真实、彼此间都有存在感就很好了，我们还能期望什么呢！

今天出门太早，不忍叫醒还在梦乡中的老婆，于是上飞机前给老婆发了一条简单不能再简单的暧昧短信（你能猜到的哦）以贺我们的结婚纪念日以及真切表达我那时那刻的心情。

此刻我在春城昆明写下此文，希望老婆能永远让我宠着，永远当我们家的“一把手”。

本文翻译自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的使用开源工具的工程最有希望达成这一目标。然而，我相信为了尽可能地接近 这个目标而付出的努力是值得的。它赋予你一种安全感：可以在任一时刻，回到过去重建旧版本的产品，并且所有人都基于同一个工具源上工作。在我看来，这些益 处要远大于其他原则引入的弊端。