为什么单元测试不是持续交付的唯一答案
为了让持续集成和持续交付(CI/CD)成为现实,企业必须审查其内部流程,并重新思考如何处理软件交付生命周期。过去的清单和评论根本不是前进的方向。残酷的事实是,大多数企业在持续交付的道路上相当落后。对软件交付过程本身进行根本性的改变与从货架上取下一些工具这样的半个步骤是完全不一样的。
如果目标是对客户和用户做出更好的响应,软件团队需要专注于软件交付周期的更快迭代,并围绕快速响应用户反馈进行组织。虽然可能有如每月发布数量这种代理指标,但采用持续交付的最佳衡量标准是跟踪从反馈到更新软件的时间。
但是如果只是拼凑性地进行持续交付,将无法达成目标。
人们很容易从渐进的角度来看待一个组织如何从现状发展到它想驻足的位置。虽然渐进永远是正确的方法,但目前仅仅迈出第一步的企业不应自欺欺人地认为自己已经走得足够远。
不要依赖于CI/CD工具
通常,团队实行持续交付都是从一些自动化的单元测试来自动化构建过程开始。这是一个很好的开端,但是不要花太多的时间去关注单元测试覆盖的代码行数。相反,企业应该将自动化测试的注意力集中在验证核心业务流程、用户事务和用户交互上,以确保它们仍然按照预期和业务有效运行所需的方式运行。
CI/CD战略的下一个复杂层次是倾向于将计划每季度进行的大量变化打包在一起(如果企业在这一步停留也是一种错误)。实际上,CI成为了企业暂停努力的一个点。另一方面,CD则是尽可能频繁地通过管道和生产进行更改。一旦企业了解了代码更改对用户的影响以及自动实现这些更改的实现方式,它就需要鼓起勇气和付出财力来推动这些更改。
一般来说,即使是正在追求CI/CD的组织,也会存在着将变革视为风险的心态。这就不可避免地导致了这样一种信念:更改的频率应该降低。这与持续交付正好相反,它会对企业完全接受CI/CD造成阻碍。
较小的变更本质上会带来更小的风险,这意味着高生产率的软件组织应能够更快地迁移。 持续交付的概念和前景取决于企业不断部署微小变更的能力。有必要期望进行频繁的发布。
范围软件相应更改
那些单纯使用传统思维方式(CI工具、单元测试和验收测试)进行这项工作的企业仍然没有获得任何真正的好处。企业正在部署的变更范围应该作为它在软件开发生命周期中可以承受的质量问题级别的指导方针。
另一个常见的问题是,当一个组织决定将事情分解为一些小的变更,但是仍然需要开一系列的会议,变更控制委员会或者开发团队必须经过的严格的安全检查。如果您的组织的目标是通过部署较小的变更堆栈来加快进度,那么在全面重新考虑内部正式的发布周期方法之前,它不会有任何进展。
在政府机构等严格监管部门工作的组织,必须通过对其发布的产品进行修改和必要的文档化来克服这些挑战。政府部门以外的组织可以效仿他们的例子,通过对软件进行更改并描述这些更改将如何影响标记版本内的用户来克服文档需求。一个很好的例子就是美国政府的cloud.gov团队如何通过编程生成文档,比如他们的系统图。
想要在CI/CD领域取得成功的企业必须找到一种方法,将这种意见编入某种可以快速完成的自动化测试中,而不是从任何人那里获取关于软件是否应该发布的意见。否则,这条道路上的每一个手动步骤只会进一步造成交付的延迟。
组织如何解决这个问题
许多企业陷入推行CI/CD至一半的境地——他们有各种各样的工具来允许一些这样的实践,但是内部流程、检查表或管理权限下的决定阻止了组织以正常的节奏发布更新。
大量的开发人员被困在传统的软件开发周期中,他们甚至不尝试CI/CD,或者通过专注于工具、测试和自动化来接受CI/CD的人工版本。
有两种方法可以解决这个问题。一种方法是首先使用CI/CD工具,并授权各种开发团队开始在公司范围内使用公共构建服务。另一种方法是确定将从较高的开发速度、较小的变更集中获益最多的开发团队,并允许从该实践中获得的经验渗透到整个业务中。
后一种模型在大多数情况下会工作得更好,因为所涉及的人员数量被保持在最低限度,而IT组织中更关心遵从性和审计的部分将有更大的灵活性来理解单个应用程序范围内发生的事情。企业应该更愿意在单个应用程序和团队中推行试验,而不是试图推动整个公司一起进行转变。
CI/CD的目标始终是不断变化的,这是有意设计的。但是请放心,当所有能够从更快交付中获益的团队都实现了这些结果时,组织将清楚自身已经开始实现CI/CD的目标。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
如何生成dubbo rpc接口文档
在国内dubbo成为很多互联网公司高并发分布式场景下rpc框架的首选,dubbo从开源至今经历过蛮多的过程,从开源到中间的停止维护,经过三年的沉寂,2017年9月,阿里巴巴宣布重启dubbo项目。到2018年2月,阿里将dubbo捐献给Apache基金会,随后dubbo经过孵化后顺利成为apache的顶级项目。 当然本文的重点不是介绍dubbo的使用,而是介绍如何利用smart-doc工具来生成dubbo的rpc内部接口文档。smart-doc因为其基于注释和java接口定义自动推导的理念,开源以来受到国内很多开发者的喜爱。在开源之初,smart-doc仅仅支持restful api文档的生成,但是在发展的过程中,不断有开发者询问smart-doc能否支持dubbo rpc接口文档的生成。经过不断努力,在smart-doc 1.8.7版本中我们增加了dubbo rpc接口的支持,下面来看看真正的操作。 一、集成smart-doc smart-doc本着使用简单的原则开发了maven插件和gradle,通过插件来降低smart-doc的集成难度和去除依赖侵入性。您可以根据自己使用的依赖构...
- 下一篇
如何在工作中快速成长?致工程师的 10 个简单技巧
作者 | 江建明 阿里巴巴高级无线开发专家 **导读:**精英人数的增长速度持续加快后,很多人开始焦虑,我也焦虑,深知要走出焦虑不容易,我想把走出焦虑快速成长的认知和方法写成文章分享给更多人,做成【技术人成长系列】文章给更多人面对面分享,该系列总共三篇,分别是《完成自己的认知升级》、《自我成长的方法》、《学会自我培养或培养他人》。本文是快速成长第一篇:“完成自己的认知升级”,内容偏长但值得仔细阅读。 如何阅读本文? 找一个固定不被打扰时间仔细阅读 在碎片化的时间中,每次读完一段内容 最重要的是每次做到只字不差的阅读,然后停下,带着批判性思维从本文中提取出你觉得对的思考方式,并把思考方式关联和迁移到自己身上,经过实践内化成自己的认知,就是非常成功的一次阅读。 开始认识“认知升级” 第一次:从文章中看到认知升级,认为认知升级是洗脑,是鸡汤,我对此不屑一顾,道理谁都懂,大部分人还不是过得一样,没啥区别。 第二次:从会场里听到认知升级,一个活人站在那里讲认知升级,觉得认知升级有点意思,开始慢慢去理解认知升级,但还是不懂认知升级的价值。 第三次:从实践中觉知认知升级,发现“鸡汤谁都懂,但依然过不...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8安装Docker,最新的服务器搭配容器使用
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装