`
shannon977
  • 浏览: 20394 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
最近访客 更多访客>>
社区版块
存档分类
最新评论

多级多粒度的持续集成 (graded and multi-scaled CI solution)

阅读更多

       也许对软件开发来说,最重要的已经不再是技术或工具、方法,而是过程。

 

在网上看了《跌跌撞撞的持续集成之路》(以下都称《路》),有一些想法,写出来和网友一起讨论。《路》中目标项目的持续集成迭代周期为一周,持续集成的任务流程为编译后台代码,后台代码单元测试,编译前台,部署,功能测试。任务流程决定了一个迭代周期内持续集成的实际执行时间。

《路》中所反应出来的问题其实就是实际集成执行时间和集成迭代周期之间的矛盾。理想情况应该是迭代周期能够包含执行时间,但实际情况却是,随着项目的扩张,当团队或代码基线变得很大时,持续集成的速度开始下降,执行时间往往有溢出迭代周期的危险。我听人说过敏捷开发对项目的规模是敏感的,它不太适于太大的项目,但是这个问题我们不展开讨论,我先不管是否敏捷开发,解决问题的思路有两个方向:

1.       延长迭代周期,让周期适应实际构建执行时间;

2.       压缩构建计划中的任务,缩短构建执行时间。

但如果单取以上两个方向任何一个去考虑,最终都会导致项目变得越来越不可靠。我的想法是两个方向同时考虑:裁减构建任务,定义多级构建计划;同时定义多粒度的迭代周期;不同粒度的迭代周期采用不同级别的构建计划。说的具体一点就是:如果构建任务集合里有编译、单元测试、功能测试、回归测试,而且都实现了自动化,则并不是每个构建计划都要包含构建任务全集,可以分为:

       编译级构建计划 只执行自动编译,目标是编译通过;

       单元测试级构建计划 执行编译和单元测试,目标是单元测试达到预期通过率;

       冒烟测试级构建计划 -执行编译、(单元测试)和冒烟测试(冒烟测试不知是否Sanity test),冒烟测试通过;

       功能测试级构建计划 执行编译、(单元测试)和功能测试(全集),目标是功能测试达到预期通过率;

       (回归测试级构建计划 -执行编译、单元测试和功能测试(全集)和回归测试,目标是功能测试和回归测试达到预期通过率;)

相应的,持续构建的迭代周期也被定义成:(小时)、天、周、()、以及Construction构建,不同粒度的周期里执行不同的构建计划。比如天构建可以执行编译级构建计划,发现的缺陷通过邮件自动及时的通知开发者,(有一个专门的角色)督促其在开发的同时改正这些缺陷。Construction构建可以执行回归测试级(甚至更严格的)构建计划,目标是可发布的稳定版本。

以上所有括号括起来的内容表示在具体实践中是可选的。总的来说,除了从CI工具和方法这点讨论解决问题的突破口,我们或者还可以从过程的角度探讨。下面将从几个方面详细论述这个多级多粒度的持续集成方案。

 

项目符合度

一个软件项目有一个总体的符合度(Compliance),这是我造出来的概念,也不知是否合适,所以也不能给出严格的定义,只能顾名思义。一个理想的软件项目总体符合度是100%。总体符合度在需求的角度表现为软件功能满足客户需求的程度,在设计和架构角度表现为设计和结构的健壮和自恰的程度,在集成和测试的角度则表现为缺陷数,缺陷越少,符合度越高。

一个实际的软件项目总体符合度理论上永不可能达到100%。从集成和测试的角度,我们用已修复或弥补的缺陷数占软件缺陷总数的一个百分比,比如80%90%甚至99%,来要求自己的工作,以保证软件符合度。

(集成和测试)符合度=已解决缺陷数/缺陷总数×100%

在项目之初,对符合度就必须有一个预期值,以便在整个项目执行过程中遵守。

另一方面一个实际软件的缺陷总数是不可知的,但如果假定测试充分,可以用已发现缺陷数逼近它,所以

       (集成和测试)实用符合度=已解决缺陷数/已发现缺陷数×100%

考虑到已发现缺陷数是缺陷总数的一个子集,我们会预设一个实际符合度比符合度高一些,比如90%99%甚至100%

 

       开发、重构以及修复缺陷的过程是不断引入缺陷的过程,集成和测试则是解决缺陷的过程。如下面的图所示,表示100%的红色虚线下的蓝实线表示预期符合度,在时间维上,项目有若干个迭代周期,则在一个周期内,开发和集成、测试交替进行,项目的实际符合度总是会慢慢的偏离预期值,之后又局部收敛到预期值。只要我们保证每个迭代周期内的局部收敛,就能期待符合度在整个项目期的总体收敛性。

持续集成和测试工作的目标就是为了保证符合度的局部收敛并最终保证总体收敛。我们现在的共识是没有、或者不充分的集成与测试工作,不能保证符合度的收敛,有可能像图中最下面一条曲线那样,实际值和预期值偏离越来越远,项目最终会被缺陷数淹死。

但另一方面,我们对过度的集成与测试工作的认识是不足的。个人认为:

l         实际执行所抱持的符合度是一个小于100%的值,应该允许一定量的缺陷留到下一个周期,甚至留到最终(这里还可以结合缺陷分级来定哪些缺陷可以留,哪些必需解决)。抱持100%符合度,或者整个项目过程中时刻抱持一个高符合度,不允许有波动,可能会导致过度的集成与测试工作。

l         如果任何缺陷都直接导致冻结新代码提交这一措施,在过度测试的情况下,其实质就是通过阻止新代码的提交来杜绝缺陷的引入。

l         在项目期间(或更确切的说一个construction期间),有一些功能或代码是不稳定的,不稳定代码引入的缺陷也可以看作是不稳定的。不稳定缺陷有可能在不稳定代码被修改、重构或删除的情况下消失。但如果在它们生存期内就解决了它们,这些工作对符合度的贡献很可能也会因为源代码的修改、重构或删除而降低甚至消失。这种情况在单元测试里表现尤其突出。

l         虽然我们可以要求项目在每一个短时间间隔内都抱持高符合度,从而让我们对总体符合度更有信心。但是那样做本质上只是缩短了符合度波动的周期,比如由一周之后重新收敛改进到一天之内就完成,因为只要有新代码的提交,就不能改变实际符合度发散的趋势。而符合度波动周期的长短对于项目最终符合度的贡献是低的。

所以过度的集成和测试工作可能缩短符合度波动周期,但项目可能会被过程中的缺陷压死。为了既不被缺陷淹死,也不被压死,我们需要适度的集成和测试工作。

下面是我的一些建议,或可减轻集成测试工作。

 

符合度要求

符合度是我们在项目期间始终关注的,对符合度的要求是可以分级的,比如可编译、可通过Sanity测试、可通过全面测试等等。符合度的要求可以和不同的迭代周期结合,比如天构建可以要求必须可编译,周(或更长周期)构建可以要求可通过Sanity测试,而为Construction的构建则必需执行可通过全面测试的要求,或者可以发布稳定版本的要求。低粒度构建就是为高粒度构建打下基础,也就是说小迭代周期构建在较低的符合度要求上的收敛,是为了避免符合度在大周期上偏离得完全不可收拾,否则我们不想被淹死也要被淹死了。反过来说,如果用Construction构建的要求来要求天构建也是不可取的,很可能被缺陷压死。

 

行动的级别

这里说对缺陷采取什么样的行动。这可以分为对单个缺陷的策略,和对一个构建周期内所有缺陷的策略。对单个缺陷是基于缺陷分级的,这个不具体展开。对于构建期内缺陷的总体策略,大概可以分为:

Fix while going on

这种级别下,开发者不必停下来专门抽时间修复,可以一边开发一边修复。但是缺陷的Owner必需被通知到,并被督促尽快修复,自动构建的邮件功能可以很好的做到这点。这一行动级别可以用于要求为“可编译”的构建。

Stop and fix a certain percent

代码提交被冻结,直到修复的缺陷达到所有发现缺陷的一个预期百分比,代码提交才恢复。这一过程可以基于缺陷的严重程度分级,比如Major以上的都必须解决,Minor的可以留到下一个构建周期解决,但必需保证修复百分比。在此需要有一个角色对每个缺陷进行分析并决定修复的策略。

Stop and fix all

和前一个级别不同的是修复百分比为100%

在后两个级别中,代码提交冻结的决策,不必依赖于自动构建是否发现缺陷和缺陷数的多少,而是可以根据构建本身的重要程度。这样就可以事先决定,并手动实施冻结。

 

迭代的周期

其实前面已经提出了构建采用多粒度周期的方案,不同的迭代周期采用不同的任务组合,不同的要求和行动级别。

 

一个专门的角色

贯彻这些标准和过程,对单个具体缺陷的行动级别做出决策,督促和协调程序员做出行动等。

 

关于Unit test

Unit test是个好东西,我在很多地方都看到别人说它的重要性,我也这样认为。我重点讨论Unit test让我为难的方面。

首先,我决定写Unit test,前期的工作量很大,许多人都主张源码未动,Unit test先行。我只能同意这一点,但在实际中我是做不到这一点的。而且正常的Unit test代码量甚至多于源代码数倍,虽然可能并不是所有的都是前期写好的,但还是能够反应出前期工作量的大!

其次是Unit test期中维护的工作量也很大。之所以这样,第一点其实是和我做不到“源码未动,Unit test先行”的原因是一样的――老实说,即便是详细设计阶段,我也只是对主要类,以及每个主要类要提供的功能有数。具体每个类里面要确切定义哪些函数,以及功能在这些函数里怎么分配,我至少没有一个清晰的概念。所以类结构在编码过程中是不稳定的,很可能一个主要类因为size的关系在实际编码时被分为几个类,函数也同样。总之我觉得我的编码过程同时也是一个重构的过程,编码在肯定、否定、再肯定、再否定中不断循环。所以在源代码不稳定的前提下,想要稳定的unit test我觉得很难。另一方面,我们采用的是增量迭代的开发过程,源代码也会随着功能的增加和改进而改变。所以说unit test 其中的维护工作量大。

Unit test实现自动执行是想对容易的事情。但如果执行结果出错,检查root cause的工作又是一个负担,因为问题到底在Unit test里还是在源代码里还两说-有没有人对unit test事先做test的?

最要命的是,在我们花了那么大的精力去维护Unit test的情况下,因为源代码不稳定,处于修改之中,unit test随之不稳定。我们的大量的维护工作的贡献度很可能因随后的修改几乎为零。

所以我建议把对unit test的处置权交给开发者,反正他们要在编码过程中用unit test检验自己的代码,维护工作可以有一个自由度。同时天构建可以持fix while going on的要求自动执行unit test,发现失败的情况,可以及时通知开发者。Construction构建则可以采用第二级要求,防着某些偷懒的程序员,也是为了以免unit test失控。

 

其实我是CISCM的初入门者。这篇帖子里的很多词汇比如项目的符合度之类的,只是我自己造出来的,再比如文中的集成和构建很多地方是混淆的。写得并不专业,时间关系也没有查阅资料以符合业界标准。文中提到的很多东西也不是我的独创,很多在实际中已经在用了。我也没有作为CISCM的专业角色操作过任何项目,以上这些只是结合我作为程序员和设计师所参与的软件项目中观察到的和体会到,并参考有关网上文章,写出来的,因此水平有限,其实用性有待证明,也请大家多指正!

 

参考网络文章

“持续集成”也需要重构——持续集成实践在Cruise开发过程中的演进http://www.kuqin.com/software-engineer/20090401/43345.html

让开发自动化: 持续集成反模式http://www.ibm.com/developerworks/cn/java/j-ap11297/

 

:跌跌撞撞的持续集成之路 http://www.infoq.com/cn/news/2008/09/road-of-ic

0
0
分享到:
评论

相关推荐

    ASP.NET某中学图书馆系统的设计与实现(源代码+论文).zip

    ASP.NET是一种基于.NET框架的服务器端编程模型,用于构建高性能、易于维护的Web应用程序。在这个中学图书馆系统的案例中,开发者利用ASP.NET的技术栈设计并实现了这样一个功能丰富的平台,旨在为中学生、教师以及图书馆管理员提供方便的信息管理和检索服务。下面我们将深入探讨这个系统的核心知识点。 1. **ASP.NET架构**:ASP.NET提供了多种开发模式,如Web Forms、MVC、Web API和Blazor。本系统可能采用了Web Forms或MVC架构,这两种模式都支持事件驱动和模型-视图-控制器(MVC)设计原则,便于创建动态网页和处理用户交互。 2. **数据库设计**:图书馆系统通常需要管理书籍信息、借阅记录、用户账户等数据,因此数据库设计是关键。可能使用了SQL Server或MySQL等关系型数据库,通过ADO.NET或Entity Framework进行数据访问,实现CRUD(创建、读取、更新、删除)操作。 3. **身份验证与授权**:为了确保系统安全,。内容来源于网络分享,如有侵权请联系我删除。另外如果没有积分的同学需要下载,请私信我。

    图书管理系统(基于ASP .NET)

    《图书管理系统(基于ASP .NET)》是一款专为学习者设计的应用程序,旨在提供一个全面的图书管理平台。系统的设计采用ASP .NET技术,这是一款由微软开发的用于构建动态网站、web应用和web服务的强大工具。ASP .NET框架以其高效、安全和易于维护的特点,深受开发者的喜爱。 该系统包含了多个核心模块,这些模块覆盖了图书管理的主要功能。有图书录入模块,它允许管理员录入图书的基本信息,如书名、作者、出版社、ISBN号、分类等。图书查询模块提供给用户方便快捷的搜索功能,用户可以根据书名、作者、关键词等条件进行检索。此外,借阅与归还模块确保图书的流通管理,记录图书的借阅状态,提醒用户按时归还,并处理超期罚款等事务。 系统还具备用户管理模块,允许用户注册、登录、修改个人信息。对于权限管理,后台有专门的管理员角色,他们可以对用户进行操作,如分配权限、冻结或解冻账户。同时,系统的统计分析模块能够生成各类报表,如图书借阅量、热门书籍、用户活跃度等,这些数据对于图书馆运营决策有着重要参考价值。 在。内容来源于网络分享,如有侵权请联系我删除。另外如果没有积分的同学需要下载,请私信我。

    思维导图制作-会计初级知识重难点-会计务实-会计基础

    本专刊的主要目的是帮助初学者系统化和结构化地掌握会计知识。我们采用思维导图的形式,将复杂的会计概念和流程进行有效的简化,旨在让学习者能够更清晰地理解这些内容,并增强记忆效果。通过视觉化的方式,读者不仅能够感受到会计知识的关联性,还能轻松掌握关键点,提升学习效率。无论是在学习新知识还是复习旧知识时,这种方法都能够为学习者提供极大的便利和帮助。

    精选毕设项目-todolist,带简易后端.zip

    精选毕设项目-todolist,带简易后端

    精选毕设项目-美食菜谱.zip

    精选毕设项目-美食菜谱

    精选毕设项目-地图定位.zip

    精选毕设项目-地图定位

    精选毕设项目-学富网家教电商平台.zip

    精选毕设项目-学富网家教电商平台

    精选毕设项目-乐租租房工具.zip

    精选毕设项目-乐租租房工具

    chromedriver-linux64_123.0.6296.0.zip

    chromedriver-linux64_123.0.6296.0

    永磁同步电机,基于扩展卡尔曼滤波算法无传感器仿真模型,s函数编写算法,基于matlab simulink搭建 附参考资料

    永磁同步电机,基于扩展卡尔曼滤波算法无传感器仿真模型,s函数编写算法,基于matlab simulink搭建。 附参考资料

    factoryio液位PID仿真程序 使用简单的梯形图编写,通俗易懂,起到抛砖引玉的作用,比较适合有动手能力的入门初学者 软件环境: 1、西门子编程软件:TIA Portal V15(博图V15)

    factoryio液位PID仿真程序 使用简单的梯形图编写,通俗易懂,起到抛砖引玉的作用,比较适合有动手能力的入门初学者。 软件环境: 1、西门子编程软件:TIA Portal V15(博图V15) 2、FactoryIO 2.4.0 内容清单: 1、FactoryIO中文说明书+场景模型文件 2、博图V15PLC程序(源码)。

    comsol光学仿真 任意偏振态BIC,利用扭转光子晶体实现远场偏振的调控,包含能带,品质因子计算以及远场辐射偏振椭圆绘制

    comsol光学仿真 任意偏振态BIC,利用扭转光子晶体实现远场偏振的调控,包含能带,品质因子计算以及远场辐射偏振椭圆绘制

    基于STM32的智能家居控制系统.zip

    STM32使用技巧,实战应用开发小系统参考资料,源码参考。经测试可运行。 详细介绍了一些STM32框架的各种功能和模块,以及如何使用STM32进行应用开发等。 适用于初学者和有经验的开发者,能够帮助你快速上手STM32并掌握其高级特性。。内容来源于网络分享,如有侵权请联系我删除。另外如果没有积分的同学需要下载,请私信我。

    基于数据驱动进化算法的风电场布局优化研究与应用

    内容概要:本文提出了一种数据驱动进化算法(ADE-GRNN)来优化风电场布局,旨在最大化风电场功率输出并减少计算时间。文中引入了自适应差分演化算法和通用回归神经网络来训练数据驱动模型,通过快速过滤低效候选解来提高求解效率。同时详细描述了风力发电机组的位置排布对功率产生成关键影响的因素如湍流效应以及不同算法(ADE、JADE、CLPSO)间的性能对比实验结果。研究表明,在多个评估指标方面,所提出的 ADE-GRNN 方法均表现出显著优势。 适合人群:对于希望深入理解智能算法在工程实践中特别是新能源领域的应用的研发人员和技术爱好者非常适合。 使用场景及目标:用于需要高效能解决复杂组合最优化问题的企业或项目组,特别是在涉及大规模风电场布局规划时的目标定位是提升能源转换率,降低成本消耗,提高运算速度。 其他说明:未来的研究可以进一步考虑更为复杂的风电场拓扑结构及更精确地模拟尾流效应,并探索三维空间下最优布局的可能性;此外还可以尝试不同的机器学习方法来稳定代理模型的表现。

    电流计算方法:.docx

    电流计算方法:.docx

    精选毕设项目-茶叶商城(含后端).zip

    精选毕设项目-茶叶商城(含后端)

    精选毕设项目-化妆品商城.zip

    精选毕设项目-化妆品商城

    chromedriver-linux64_123.0.6286.0.zip

    chromedriver-linux64_123.0.6286.0

    智慧图书管理系统设计与实现-springboot毕业项目,适合计算机毕-设、实训项目、大作业学习.zip

    Spring Boot是Spring框架的一个模块,它简化了基于Spring应用程序的创建和部署过程。Spring Boot提供了快速启动Spring应用程序的能力,通过自动配置、微服务支持和独立运行的特性,使得开发者能够专注于业务逻辑,而不是配置细节。Spring Boot的核心思想是约定优于配置,它通过自动配置机制,根据项目中添加的依赖自动配置Spring应用。这大大减少了配置文件的编写,提高了开发效率。Spring Boot还支持嵌入式服务器,如Tomcat、Jetty和Undertow,使得开发者无需部署WAR文件到外部服务器即可运行Spring应用。 Java是一种广泛使用的高级编程语言,由Sun Microsystems公司(现为Oracle公司的一部分)在1995年首次发布。Java以其“编写一次,到处运行”(WORA)的特性而闻名,这一特性得益于Java虚拟机(JVM)的使用,它允许Java程序在任何安装了相应JVM的平台上运行,而无需重新编译。Java语言设计之初就是为了跨平台,同时具备面向对象、并发、安全和健壮性等特点。 Java语言广泛应用于企业级应用、移动应用、桌面应用、游戏开发、云计算和物联网等领域。它的语法结构清晰,易于学习和使用,同时提供了丰富的API库,支持多种编程范式,包括面向对象、命令式、函数式和并发编程。Java的强类型系统和自动内存管理减少了程序错误和内存泄漏的风险。随着Java的不断更新和发展,它已经成为一个成熟的生态系统,拥有庞大的开发者社区和持续的技术创新。Java 8引入了Lambda表达式,进一步简化了并发编程和函数式编程的实现。Java 9及以后的版本继续在模块化、性能和安全性方面进行改进,确保Java语言能够适应不断变化的技术需求和市场趋势。 MySQL是一个关系型数据库管理系统(RDBMS),它基于结构化查询语言(SQL)来管理和存储数据。MySQL由瑞典MySQL AB公司开发,并于2008年被Sun Microsystems收购,随后在2010年,Oracle公司收购了Sun Microsystems,从而获得了MySQL的所有权。MySQL以其高性能、可靠性和易用性而闻名,它提供了多种特性来满足不同规模应用程序的需求。作为一个开源解决方案,MySQL拥有一个活跃的社区,不断为其发展和改进做出贡献。它的多线程功能允许同时处理多个查询,而其优化器则可以高效地执行复杂的查询操作。 随着互联网和Web应用的快速发展,MySQL已成为许多开发者和公司的首选数据库之一。它的可扩展性和灵活性使其能够处理从小规模应用到大规模企业级应用的各种需求。通过各种存储引擎,MySQL能够适应不同的数据存储和检索需求,从而为用户提供了高度的定制性和性能优化的可能性。

    (螳螂voc数据)农作物病虫害识别目标检测数据集,VOC格式,螳螂数据集,纯手动标注,用来进行目标检测代码训练的数据

    (螳螂voc数据)农作物病虫害识别目标检测数据集,VOC格式,螳螂数据集,纯手动标注,用来进行目标检测代码训练的数据。

Global site tag (gtag.js) - Google Analytics