持续集成指引.docx

上传人:p** 文档编号:574155 上传时间:2023-11-08 格式:DOCX 页数:4 大小:16.96KB
下载 相关 举报
持续集成指引.docx_第1页
第1页 / 共4页
持续集成指引.docx_第2页
第2页 / 共4页
持续集成指引.docx_第3页
第3页 / 共4页
持续集成指引.docx_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《持续集成指引.docx》由会员分享,可在线阅读,更多相关《持续集成指引.docx(4页珍藏版)》请在第壹文秘上搜索。

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

2、同时注意到趋势并进行有效的决策,提升团队的整体研发质量:Q)有效决策:持续集成系统为项目构建状态和品质指标提供了及时的信息,有些持续集成系统可以报告功能完成度和缺陷率。(2)注意到趋势并改进:由于经常集成,我们可以看到一些趋势,如构建成功或失败、总体品质以及其它的项目信息,并据此进行改进。目标频繁进行自动化构建、发布、自动化测试,尽早发现错误,提高交付效率。原则 所有的开发人员需要在本地机器上做本地构建,然后再提交的版本控制库中。 开发人员每天至少向版本控制库中提交一次代码。.开发人员每天至少需要从版本控制库中更新一次代码到本地机器。 修复失败的构建是优先级最高的事情。规范提交前 必须:每一次

3、commit被push到远程仓库,就会触发一次构建。 必须:外部依赖来源于集团统一制品库。 必须:本地先合并远程变更,构建通过再提交远程仓库。集成时必须构建过程必须包括单元测试,静态扫描。不通过,视为构建失败。.必须对于master分支每次修改后,需即刻触发构建,并执行全部检查步骤。建议非master分支每次修改代码后,即刻触发构建,也进行全部的检查动作,如安全扫描,自动化测试。构建后必须:构建结果需要通知到团队成员。.必须:构建失败之后不要提交新代码,要么修复,要么回滚。.必须:构建成功的产出物,标记好版本,放入制品库。推荐实践.真正做到测试驱动开发。 若违背架构设计原则,就让构建失败。,若

4、单个测试案例运行超时,就让构建失败。 若有编译警告或技术债务超限,就让构建失败。日常开发开发者完成开发和单元测试使用Sonar或ide自带的插件完成质量自检。开发者向版本控制库提交代码,所有后面的步骤都始于本地代码的一次推送(push)0在推送发生之后,Cl服务器检测到版本控制库中发生了变更,CI服务器会从库中取得最新的代码副本,对软件进行构建和集成。CI服务器通过邮件等方式向指定的项目成员提供构建结果的反馈信息。指标 每(日周月)MR到master的次数 每(日周月)通过master构建成功、失败的次数 构建失败中,各类型失败占比 每次构建、自动化测试所花时间.构建失败到修复所花费的时间(平均、最长)

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 管理/人力资源 > 质量管理

copyright@ 2008-2023 1wenmi网站版权所有

经营许可证编号:宁ICP备2022001189号-1

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。第壹文秘仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第壹文秘网,我们立即给予删除!