议题：请教一下，如果想搞日构建，需要达到什么样的条件才能做这个事情
一、日构建前置条件
按照以往的经验,至少要具备
1. 工程的命令行编译(ant,maven,msbuild,devenv之类)
2. 一体化的环境配置和释放能力
3. 一键式部署的能力
4. 足够多的各类测试的支撑
5. 丰富多元化的结果呈现
只要项目具备可以稳定编译和测试的过程，日构建随时都可以。
构建初期可以只编译，逐渐加上ut，bvt测试，代码扫描等子过程。
持续集成最重要的环节是编译，单元测试，自动化测试，这三块。
节省人力成本这块，我之前在测性能的时候，实际上引入了持续集成，我脚本感知代码变更，然后编译生成性能测试代码，然后自动部署，测试，收集结果，曲线展示。
单元测试主要是开发人员来写，自动化测试需要测试人员来做，所以我这里把它分开了，并且单元测试是基础，所以需要赢得上层的支持，才能驱动开发来做。
问：代码变化，有可能会造成你的性能测试脚本失效维护失效脚本的开销，有统计吗？
答：代码只要有提交，就会触发流程，进行性能测试。如果有接口方面的改动，肯定要修改测试代码的。开销没有详细统计，但是已经能感受到轻松了许多，因为每天都会跑曲线出来。
二、 名词解释
BVT是Build Verification Test
MS的流程如下：
fix bug -> static analysis -> code 2 bbpack -> bubby build -> check-in -> ut -> build -> deploy -> api\uia -> IDX -> preformance -> XXXXXXXXX -> mail report 2 all.
持续集成（Continuous Integration）
ut和api\uia test的主要功用就是回归
这个之前我一直在说,CI的最大作用就是在开发提交每次代码的10分钟之内,就应该知道这次代码提交有没有引起原来的bug
三、CI优缺点
一） CI的相关成本：
1. 公司领导的支持和推进
2. 项目成员的观念改变
3. QA流程持续改进
4. 框架和工具的熟悉和环境搭建
5. 测试案例设计和开发，包括单元测试，静态代码分析，冒烟测试，集成自动化测试等
6. 测试脚本的开发和维护，如果UI部分变化大，这部分的维护effort会比较大。
7. Daily build的测试报告的收集与分发
8. 问题定位与解决
二） CI的好处
1. 每天都有交付物
2. 可以在尽早的环节，发现问题，解决问题，降低后期风险。 （参考defect的时间与风险/成本曲线）
3. 从总体上看，敏捷度会提升，项目schedule会比较紧，大部分情况下会压缩项目的duration。 也就是说会比较tough，但是效率会提升。
三） CI可能不爽的地方
1. 开发过程中，可能会有一些中间状态存在。这样的话，可能会需要部分的时间频繁处理“中间状态”相关问题。 而这些问题在非CI开发模式下，有可能会自然而然消除。
2. 目光较多放在碎片化任务上，如果需要较长时间处理核心业务的话，会受到一定影响。
3. 团队成员压力会比较大，如果前景或者个人收益不明显的话，团队可能不稳定。
四、 总结的几条做CI的软实力规范：
1.经常提交代码（签入不够频繁，这会导致集成被延迟）
2.不要提交无法构建的代码（容易造成构建失败）
3.立即修复无法集成的构建（破碎的构建，这使团队无法转而执行其他任务）
4.编写自动化的开发者测试（第一道质量保障：单元测试）
5.必须通过所有的测试和审查（针对不同项目设置不同审查标准）
6.执行私有构建（开发人员自己的私有环境要保障）
7.避免签出无法构建的代码（增加修复代码前务必保障获取到最新的稳定代码）
8.避免超长时间的构建（保持构建过程不超过N小时）
例子：
举个栗子吧，构建一台自行车。
开发把零件准备好，做好零件级的测试，没出现零件问题，ut测试通过
构建脚本把零件拼起来，生成一辆自行车，没出现零件组装不起来的情况，编译通过
测试把车子骑上原地转几圈，没问题，bvt测试通过
至于车子能跑几公里，能在什么样的路面上跑，这个就是性能测试，异常测试等方面的问题了。
五、 考核KPI
c++ coverage
java maven
或者前期可以使用如下指标考核：
如果想搞日构建，需要达到什么样的条件才能做这个事情,布布扣,bubuko.com
原文：http://www.cnblogs.com/duyy/p/3596678.html