持续集成指引.docx

持续集成指引概念关于持续集成、持续交付等概念的区别，请参考持续集成-持续交付-持续部署。持续集成(ContinuousIntegration)是一种软件开发实践，即团队开发成员经常集成它们的工作，每次集成都通过自动化的构建(包括编译，发布，自动化测试)来验证，可以让团队在持续的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。不采用持续集成的情况下，总会有问题到交付前的集成测试的时候才发现，可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致严重的生产事故。采用持续集成的方案可以让我们同时注意到趋势并进行有效的决策，提升团队的整体研发质量：Q)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。(2)注意到趋势并改进：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息，并据此进行改进。目标频繁进行自动化构建、发布、自动化测试，尽早发现错误，提高交付效率。原则 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中。 开发人员每天至少向版本控制库中提交一次代码。.开发人员每天至少需要从版本控制库中更新一次代码到本地机器。 修复失败的构建是优先级最高的事情。规范提交前 必须：每一次commit被push到远程仓库，就会触发一次构建。 必须：外部依赖来源于集团统一制品库。 必须:本地先合并远程变更,构建通过再提交远程仓库。集成时必须构建过程必须包括单元测试,静态扫描。不通过，视为构建失败。.必须对于master分支每次修改后,需即刻触发构建，并执行全部检查步骤。建议非master分支每次修改代码后,即刻触发构建，也进行全部的检查动作，如安全扫描，自动化测试。构建后必须：构建结果需要通知到团队成员。.必须：构建失败之后不要提交新代码，要么修复，要么回滚。.必须：构建成功的产出物，标记好版本，放入制品库。推荐实践.真正做到测试驱动开发。 若违背架构设计原则，就让构建失败。,若单个测试案例运行超时，就让构建失败。 若有编译警告或技术债务超限，就让构建失败。日常开发开发者完成开发和单元测试使用Sonar或ide自带的插件完成质量自检。开发者向版本控制库提交代码，所有后面的步骤都始于本地代码的一次推送（push）0在推送发生之后，Cl服务器检测到版本控制库中发生了变更，CI服务器会从库中取得最新的代码副本，对软件进行构建和集成。CI服务器通过邮件等方式向指定的项目成员提供构建结果的反馈信息。指标 每（日周月）MR到master的次数 每（日周月）通过master构建成功、失败的次数 构建失败中，各类型失败占比 每次构建、自动化测试所花时间.构建失败到修复所花费的时间（平均、最长）