持续集成指引_第1页
持续集成指引_第2页
持续集成指引_第3页
持续集成指引_第4页
全文预览已结束

付费下载

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

持续集成指引概念关于持续集成、持续交付等概念的区别，请参考持续集成-持续交付-持续部署。持续集成（ContinuousIntegration）是一种软件开发实践，即团队开发成员经常集成它们的工作，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，可以让团队在持续的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。不采用持续集成的情况下，总会有问题到交付前的集成测试的时候才发现，可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致严重的生产事故。采用持续集成的方案可以让我们同时注意到趋势并进行有效的决策，提升团队的整体研发质量：

(1)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。

(2)注意到趋势并改进：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息，并据此进行改进。目标频繁进行自动化构建、发布、自动化测试，尽早发现错误，提高交付效率。原则所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中。开发人员每天至少向版本控制库中提交一次代码。开发人员每天至少需要从版本控制库中更新一次代码到本地机器。修复失败的构建是优先级最高的事情。规范提交前必须：每一次commit被push到远程仓库，就会触发一次构建。必须：外部依赖来源于集团统一制品库。必须：本地先合并远程变更，构建通过再提交远程仓库。集成时必须：构建过程必须包括单元测试，静态扫描。不通过，视为构建失败。必须：对于master分支每次修改后，需即刻触发构建，并执行全部检查步骤。建议：非master分支每次修改代码后，即刻触发构建，也进行全部的检查动作，如安全扫描，自动化测试。构建后必须：构建结果需要通知到团队成员。必须：构建失败之后不要提交新代码，要么修复，要么回滚。必须：构建成功的产出物，标记好版本，放入制品库。推荐实践真正做到测试驱动开发。若违背架构设计原则，就让构建失败。若单个测试案例运行超时，就让构建失败。若有编译警告或技术债务超限，就让构建失败。日常开发开发者完成开发和单元测试，使用sonar或ide自带的插件完成质量自检。开发者向版本控制库提交代码，所有后面的步骤都始于本地代码的一次推送（push）。在推送发生之后，CI服务器检测到版本控制库中发生了变更，CI服务器会从库中取得最新的代码副本，对软件进行构建和集成。CI服务器通过邮件等方式向指定的项目成员提供构建结果的反馈信息。指标每（日周月）MR到master的次数每（日周月）通过mast

人人文库> 全部分类> 教育资料 > 辅导培训

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论