【DevOps】我们忽视了Daily Build（每日构建）吗？

一、什么是Daily Build？

二、为什么要做Daily Build？

1、可以让同事从日常工作中养成质量意识。

2、及时发现问题

3、最小化集成成本。

三、如何有效的做Daily Build？

1、工具协同

2、制定标准

3、“积跬步”

一、什么是Daily Build？

每日构建，简而言之就是每天把当前最新的代码集合拉取下来，然后进行编译构建并进行自动化的冒烟测试，然后通过某种形式把构建结果进行系统性展示给相关干系人。这是持续集成的其中一项最佳实践，最早出现在微软，我个人认为这是放之四海而皆准的一个原则，只是不同公司的实际操作会有异同。它的目的不是在于减少构建失败的次数，而是要尽早发现问题，降低解决问题的成本。

二、为什么要做Daily Build？

1、可以让同事从日常工作中养成质量意识。

为什么会这样说呢？实际上我翻阅过我团队中的很多SIT缺陷，很多都是一些低级代码错误造成（如越界问题、公共代码改造导致原有功能错误），通过单元测试大部分都是可以避免的。为什么大家不做呢？当然原因有千百种，有时间不足的、有思考欠周全的、有侥幸心理的。从整个项目周期来看，看起来初期研发速度是快了，但是后期SIT或UAT阶段由于低代码质量带来的各环节返工成本（如缺陷确认、代码修复、重测等）却比编写单元测试的成本要长。

这里简单介绍一下什么是“安灯绳”。

“安灯绳”源自于丰田公司。在丰田的实践中，每个工作中心都是一条线索，当某个环节出现问题时安灯绳会被马上拉响，团队领导第一时间马上解决问题，如果问题不能在指定时间内解决，就会停掉生产线并调动整个条线一起协作直到成功找到解决问题对策为止。

Daily build的目的还不仅仅是为了检查出问题，它的更深层意义是为团队建立这样一个“安灯绳”（Andon）。就像上面讲到的安灯绳一样，只有灯一亮，留给员工的反应时间是很短的（记住是负责那个出问题环节上的那位员工），因为当他按下灯的那一刻他不是站着等领导过来，而是他要马上去想解决方案，那他解决方案的有效性就取决于他对这个流水线上其他位置的工作内容的了解，这样就会促使他平时会主动去了解流水线上的其他环节的工作，这样的话就会潜移默化的迫使每个员工去培养具备系统思考及质量意识。

2、及时发现问题

开发人员的日常工作就是进行不断的设计和对假设进行验证，如果我们能定位和解决问题的速度越快，那我们的敏捷性和响应力就越快。在技术价值流中，如果缺少快速反馈机制，工作结果（即产出）究竟如何是很难去评估的。

例如，在瀑布开发流程中，如果我们的交付只有在SIT集成测试才能反馈的话，那我们的一次交付质量究竟是什么水平？很多人会说“嗯，挺好的”。但是如何界定挺好呢？没有量化的数据可以进行分析统计。如果用了Daily build的话，我们可以通过数据（构建时间、构建测试通过率等指标数据）了解到我们的交付质量问题主要集中的地方，而且是在构建环节就可以知道。

3、最小化集成成本。

如果团队里面使用的是类似Gitflow的源代码版本管理规范的，那使用这个Daily Build就更加有必要了，具体原因可以参考我的另外一篇文章《源代码、编译包版本管理团队实践》。

这里回顾一下Gitflow这种branch based模式的版本管理的劣势及Daily build是如何去解决或缓解这些问题的。

合并冲突：合并冲突在使用 Git Flow 是非常普遍的，原因也很简单：多个功能分支长时间并存，如果多个分支也刚好改到相同的部分，合并冲突带来的成本（如构建成本、人肉审核成本、沟通成本）的高低就取决于团队成员什么时候拿着杯茶好好的坐下来一起合并代码了。如果你基本在快进入SIT测试阶段才来合并，那恭喜你未来一到两周决定拿着枕头回公司吧。
功能冲突：在合并到同一个分支之前，你不能测试两个功能的组合。当你在单独的分支中开发几天甚至几周的功能时，当合并时可能会发生两个功能的相互作用影响了你的代码。
合并恐惧：大家都知道越早合并越好，但是在跟团队一起合并代码时还是会有“恐惧”，因为合并意味着错误，错误意味修复，修复意味着时间投入。那我们为什么还要每天合并，直接搞一个每周合并不是更省事吗？反正每天提交的代码质量肯定没有每周提交的考虑得周全。

如果团队习惯了Daily build的话，可以把合并冲突的解决阶段限制在发生问题的第二天，那这样的的解决成本就相对很低。你认为修复一个bug的平均成本是多少？之前在伦敦召开的2009 XP日会议上，Google的Mark Striebeck报告了Google对延迟修复缺陷的成本估计（如下图）。看到以下的成本，大家就会知道为什么我们需要尽早修复故障啦，对不对？

（本数据摘自Lasse Koskela的《有效的单元测试》一书中的第1章，第1.2节）

三、如何有效的做Daily Build？

1、工具协同

What is culture? Culture is what we behave.

我一直倡导的是认同和文化，但是文化一开始是怎么建立的？除了千篇一律的循循教导以外（当然这个很重要），我觉得另外也很重要的一点是工具，这里讲的工具是广义的工具，包括表单、流程、规范、系统等，这是我对团队文化的一个理解。

那工具能够帮我们做什么？

固化流程、强化团队行为，久而久之团队养成的行为习惯就是团队文化，潜台词是它能加速文化的形成；

能够实时纠偏。想象一下高速公路两旁的围栏，它就是纠偏的“工具”。如果触碰到“工具”的底线是要吃亏的。

大话说了那么多，那我们应该要怎么做？实际上的Daily build就是包含了基于每日的代码合并，按设定时间自动编译、打包、测试、元数据收集的一个整体框架，这也是构成整个配置管理（SCM）的核心活动。我大致画了一个图表用于展示整个Daily build的流程。

具体在Jenkins如何配置定时构建，可以在相应的Job的配置项中的“构建触发器”上面勾选“Build periodically”（如下图）。另外，具体的“日程表”配置有点类似crontab，这个语法可以自行网上搜索。

另外，涉及到基于Jenkins的自动编译、打包、测试的，可以参考我之前的另外系列的几篇文章：

【DevOps】Jenkins持续集成流水线（上）

【DevOps】Jenkins持续集成流水线（中）

2、制定标准

为了保证每个daily build都是能严格执行（包含构建、检查失败情况、修复问题、重新构建等一系列动作），那就需要制定具体可落地的团队标准以便通过质量关卡（即上图中的质量门禁）。并且，这个标准是要明确的错误分级，保证既要解决重大或中等级别的问题，又要能有一定的灵活性（即自由裁量权）给到团队成员进行内部评估以便忽略某些无关紧要的错误（如环境配置问题）。

3、“积跬步”

在Daily build中的其中一环是要在构建后进行冒烟测试（没有冒烟测试的daily build都是耍流氓）。但是冒烟测试不是要求面面俱到，还是套用测试金字塔的理论，我们应该针对测试进行测试分层。

在团队内部，可以针对系统所有接口或流程进行等级划分，团队在一开始使用该实践的时候没必要求大求全，可以在Daily build的实践中先行把重要等级的接口或流程纳入到冒烟测试集中（其他等级一概不纳入），这样做的关键之处还是在于帮助团队建立成功的成就感，团队更加愿意做这个事情，慢慢的这种实践就会内生在团队中。