最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

简讯:通过持续交付提升发布效率

来源:博客园

前期我们提到,在研发过程中,可能由于迭代变化或需求调整等等原因会导致团队欠很多技术债,从而导致随着项目的运行,技术债务越积越多,导致给用户交付越来越慢,交付的软件质量越来越差,最终不可控,拖延整体交付进度,系统不可控等很多问题。

在实际研发工作过程中,我们基于一些工程学的方法,借助一些工具与方法,结合科学的流程,能够对降低技术负债起到一定的作用。

最近笔者学习和阅读了一些技术类书籍,其中领导推荐的一本《持续交付发布可靠软件的系统方法》书籍中所提到的理念和实践方法,对提升发布效率、减少技术债等就有一定的帮助,可供软件研发实践参考。


【资料图】

下面就结合笔者的一些实践,以及该书的一些理念,仅仅从持续交付中一些小的点来做一些分享,在实践中可以作为一些参考,可以帮助改善工作质量,减少一些技术债务,提高持续交付的质量和效能。

提到持续交付,我们都知道,它是一种软件工程手法,其目的让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以发布的状况。软件研发过程中,我们不仅仅要保证软件产品当前可用,而且希望保证它持续长时间可用,甚至随时随地有了需求的变更后,都能够快速实现、快速完成、快速部署和交付。尤其是当软件面临客户的紧急需求变更时候的交付诉求,这种能够快速交付的能力就显得尤为重要。

一、持续交付的目标

持续交付的目标在于让软件的构建、测试与发布变得更快以及更频繁。通过这种方式来减少软件开发的成本与时间,减少风险。持续交付往往与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中,但是出于业务考虑,可以选择不部署。如果要实施持续部署,必须先实施持续交付。持续交付往往伴随着持续部署,与自动化测试及自动化部署配合开展,几项工作之间相互协调,相辅相成。

二、关于持续交付

关于持续交付,我们接下来尝试分享和回答下面几个问题:

1)持续交付是在解决什么问题,为什么要做持续交付,它能带来什么?

2)持续交付怎么做?持续交付什么时候做?

首先,看第一个问题,持续交付在解决什么问题。关于交付,从在不同的角度对交付进行解读会有不同含义,面对用户的交付,面的客户的交付,面对甲方乙方,做一款产品的交付,做一个项目的交付,其交付方式,交付质量,交付物可能都是有一定差别的。我们这里缩小范围,仅描述研发团队对用户的软件交付,讨论持续交付如何实践。

对于产品研发团队来说,产品的版本的更新迭代和交付,最终经过集成测试、系统测试等测试后的软件版本通过部署交付到用户环境,最终调试跑起来,达到可提供给客户服务和使用的状态即理解为软件交付。

在交付之前,我们需要进行多轮回归验证,经过单元测试、配置项测试、集成测试、系统验收测试,兼容性测试,发现软件缺陷之后,Bug修复之后的回归测试。而我们希望每一轮的回归测试能够尽可能快,Bug修复能够不带来新的问题,开发人员在引入任何回归错误时(包括缺陷、性能问题、安全问题、可用性问题等),都能快速得到反馈。只有快速发现问题,快速修复问题,快速反馈问题修复结果,才能让整个环节加速。一旦发现软件中的问题,就立即加以解决,从而保持代码的主干master随时都始终处于可部署状态,这样就实现了一定意义上的快速实现,再加上这个过程中,代码compile、代码build,都是以工具方式,通过代码驱动,那就初步实现了持续集成。

我们希望通过持续集成,结合持续交付的作用,将集成后的代码部署到类生产环境,确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题,可以继续手动部署到生产环境中。

对于项目实施团队来说,持续交付是要将客户要求实现的功能部署到客户的生产环境,通过验收即为交付。对于最终用户来说,持续交付是最终用户可以使用相关的功能即为交付。持续交付是指持续的将各类变更(包括新功能、缺陷修复、配置变化、实验等)安全、快速、高质量地落实到生产环境或用户手中的能力。持续交付的能力通过自动化流水线的方式实现,减少研发过程中不必要的浪费,近而缩短整个研发过程中所有需求的交付周期。持续交付是一个整体过程,从一个业务端的想法到系统功能可以面对客户的全流程。简单来讲就是,持续交付能够帮助提高交付效率,节约成本。

其次,持续交付怎么做?建议在项目初期,项目立项时候,就开始着手准备,根据项目的形态,是分布式,还是单体应用,是单独的信息管理系统,还是需要多端交互的系统,基于公有云、还是私有化部署等等,结合项目的实际分析,具体选择是直接写脚本,还是通过工具完成。持续交付开展越早越好,越是前期,模块越小,集成时候出错概率越小,遇到问题也容易解决,越是大规模多模块的复杂系统,软件问题的处理难度越大,耗费的时间也越多。

尽早开展持续集成,尽早让测试介入,这条原则,在软件工程实践中,强调多次都不为过。持续交付适合建立了发布流水线,有单元测试与自动化测试的团队做,要想持续交付,通过这些脚本去测试业务代码,能够实现对结果的快速反馈。而前几年流行的TDD模式,就是在通过强调写业务代码之前,需要先写好单元测试测试代码,并将单元测试代码集成,通过测试代码验证业务代码的方式提高业务系统软件质量。在这样的工作模式下,通过测试代码驱动开发业务代码,我们对于覆盖率提出一定数量方面的要求也很有帮助。

三、持续交付的发法和原则

在实际开展持续交付过程中,也可以根据实际情况进行,有些界面设计之类可能根据用户喜好不同,风格变化可能比较频繁,此类工作不可少,但是又不影响代码构建,对于此类,我们可以另辟分支开展。针对业务代码,可以考虑参考这几个原则开展:

◆坚持精简原则,选择适合自己业务的来实现,尽可能拆分模块,细化小模块做持续交付。

◆持续尽早开展,并分解问题,不断试错纠错,在不断的支持分解和解决问题中持续优化交付流程。

◆坚持快速反馈,不是一味的埋头苦干,提早确认和反馈风险,在快速反馈中,尽早完成和解决问题。

◆持续改进并衡量,改进和衡量方式同样重要。

前期做好规划,尽早开展,在实际开展过程中,不断分析优化,持续解决问题,随后进行问题回归与验证,作为下次优化的起点。采取PDCA工作模式,不断执行-检查-分析-调整,持续迭代。而这种小规模,小版本迭代,小步快跑的方式,有助于提升持续交付成功率。

我们建议频繁提交,小代码块提交。尽量避免很长时间不提交,却一次性提交大量代码,这种方式,一旦提交后构建失败,导致对问题的分析定位也是耗时巨大。少量代码频繁提交,每个模块只做每个模块的事情,于软件设计模式清晰,也对代码构建有好处,提交后即使出错,也好排查。易于快速迭代,实现快速编译、快速构建、有助于快速交付。

四、持续交付的实践

在软件团队,我们知道以前有一个角色叫做SCM,软件配置管理工程师。他专门会负责代码的构建、集成,以及配置项、代码基线与版本等的管理。但近年来,随着DevOps的流行,加上敏捷的口号,该职位只在一些大中公司中存在,但SCM的关键性毋庸置疑。软件的集成,软件的配置项,代码管理等环节,是软件能够从零散的代码得以组装,成为可执行可运行的软件的必要环节,于交付而言不可或缺。

SCM工程师在软件配置管理过程中的这些活动:配置标识、配置控制、配置状态发布、配置的评审,现在逐步融入在持续集成环节。配置管理是软件生命周期里,对定义各类配置项,建立各类基线、描述相关软件配置项及其文档的过程很重要。在持续交付过程中,把一些之前需要手动操作的,通过脚本或工具连起来,用代码去自动化的实现,有助于落地持续交付。逐渐借助一些工具,在实践中能够帮助我们实现持续交付,比如以前就有cruise control、hudson、Jenkins、 TeamCity、等一些出名的CICD工具,随后出现了Travis CI、Gitlab CI等;但是Jenkins由于其免费,跨平台,支持docker化安装,支持上千个插件的扩展版本,可以集成几乎所有市场上可用的工具和服务,现在依然收到很广泛的使用。Jenkins支持插件化安装并扩展为最大的开源CI工具之一,可帮助工程团队自动化部署。在实际的开展过程中,可以参考相关帮助文档进行,关于jenkins的实践与应用使用,网上资料很多,这里暂不展开详细描述具体工具的使用细节。

五、写到最后

持续交付并非一蹴而就,我们可以借助一些工具结合实际业务快速实现,结合持续集成、持续交付、持续部署几个活动相辅相成,经过在项目中的磨合实践、调试、优化,并最终形成适合团队的持续交付工作流程。在实际中,可能项目不同,业务不同,也需要适当调整。可以根据实际业务的规模,以及项目周期的长短,选择适当的工具,能够最快速的用于解决项目实际问题,助力快速交付,才是最好的。

关键词: 生产环境 单元测试 解决问题