部署和发布是软件工程中经常互换使用的两个术语,甚至感觉是等价的。然而,它们是不同的!
部署是发布的前提,只有当软件已经成功部署后,才能进行发布。缺乏发布管理会导致发布不规则、手动交付过程、数据库更新问题、协作问题等。
如下,简单归纳了发布&部署的差异:
日常研发活动中,我们会经常听到下面的说法,感觉有点差别,又感觉一头雾水说不清楚区别在哪里。
下面对上述关键词进行了总结归纳
说明:发布的版本未必是正式版,比如发布测试版(如Beta版)、试用版、演示版。发布之后,受众可以获得软件,但不一定就使用它。发布的软件可以存储在VCS(版本控制系统)中或制品库中,也可以存储在光盘等介质上。受众获得软件之后的下游动作,不一定是部署,也可能是其他动作(如交付或其他)。如:
发布测试版-->部署到测试环境-->交付给测试人员做验收测试。
发布正式版-->部署到生产环境-->交付给用户使用。
发布正式版产品(如windows安装盘)-->(售卖)交付给用户 --> 部署 -->上线使用。
特征:发布物有(标签)标识,提供出来可以获得。
举例:开发人员发布了一个测试版。开发团队在每个月都会发布一个演化版。某产品发布了新的版本,用户需要重新购买后,才能部署升级。某云平台发布了新的版本,不需要用户部署就可以使用新的功能。本次版本发布了,但没有人使用。
对于上面的概念解释,可能你会觉得有什么用呢?能解决什么问题呢?不妨按照以上的定义,把开头的那段话,进一步解读,得到如下信息:
除了集成是开发完成后首先完成的外,其它几个活动没有固定的依赖关系,它们的先后顺序需要根据具体的应用场景。
某乙方公司为甲方公司开发了一个web应用,需部署到生产环境,再发布给甲方公司,交付给使用部门(用户),使用部门才能投产使用(上线),那么它们的先后顺序就是:集成—>部署—>发布—>交付—>上线。
A公司开发了一个SaaS应用,部署到生产环境,交付给B公司,B公司再加入自己公司的基础数据后上线了该SaaS应用,发布给使用部门(用户)使用,那么它们的先后顺序就是:集成—>部署—>交付—>上线—>发布。
还有更多场景,就不列举了。
A公司开发了一个商用软件,发布到网上,B公司通过购买获得,由A或B公司的技术员将软件部署到B公司的生产环境,交给B公司的使用部门(用户),使用部门才能投产使用(即上线),那么它们的先后顺序就是:集成—>发布—>部署—>交付—>上线。
早年,微软发布了Window XP(存储在光盘中),交付给用户,用户再部署到生产环境,然后投产使用(上线)。现在的很多单体软件,大多也是这样的流程。那么它们的先后顺序就是:集成—>发布—>交付—>部署—>上线。
对于互联网应用服务,互联网厂商一般会进行集成(频率集成),通过自动化方式部署到dev/test/uat等环境,通过一定的审批机制获得部署到prod环境的授权(蓝绿、灰度等),正式发布上线,交付给用户使用
那么它们的先后顺序就是:集成—>部署—>发布—>上线—>交付
通过以上分析,你对“集成”、“部署”、“上线”、“交付”、“发布”的概念的理解是否清晰了?
上面说了这么多,目的不是为了死记某些概念,而是想说明,不同组织、产品形态不同,部署发布方式差异很大,在设计持续交付 (CD) 流程之前,需要了解关于部署、发布的素有信息。
从代码提交到集成,再到功能验证,再到被部署到不同的环境,中间涉及了“代码提交信息”,“制品信息”,“环境配置信息”等,不同的发布方式,这些信息的传递和保存方式也各不相同。理解吃透这些差异,才能设计出来有意义的交付流程。
另外,发布管理是ITIL服务管理框架中的一个重要流程,主要负责计划、实施和控制IT服务的变更,确保变更过程中各个环节的顺利进行。
发布管理关注的是将经过测试并导入实际应用环境的新增或改进的配置项分发到最终用户,并确保这些配置项能够安全、可靠地运行。
因此需要在发布计划、包和构建发送进行测试之前进行广泛的规划,主要涉及
另外,软件版本需要适当的管理以避免与未来版本相关的问题。
这里,从不同角度归纳一些关于发布的案例**。一般来说,需要提前制定发布计划,并且由专人(例如release manager这样的角色)负责管理发布计划。release manager 作为研发团队(研发执行)和客户(需求变更)之间的桥梁,清楚了解每次发布的变更,以及影响客户的范围。**
2016 年,联合航空为超过 1.43 亿用户提供服务。然而,软件发布管理是一个巨大的挑战。有几个手动流程和电子表格,这增加了发布周期时间。
因此,联合航空公司选择通过转移发布团队的角色来利用在岸/离岸发布模型,以确保完成特定的承诺。他们的发布管理方法最好的部分是使用 DevOps 和集中治理模型。他们设法通过持续交付团队 (CDT) 和开发团队之间的协作来简化发布。
Firefox的发布流程:每个独立的发布火车(新的发布过程采用火车模型,固定的“发车”时间,特性的发布取决于该特性是否赶上最近的火车发车时间)包括6周的开发时间加上12周的稳定时间:
除了发布计划,这里也需要分支策略的配合 (新的开发成果不会直接发布到Aurora和Beta分支上,这些分支需要被开发人员和社区测试人员共同测试完方可;如果发现开发中存在程序问题或者BUG,就需要先解决问题)
对于发布,市场上少有平台会关注这个环节。笔者过去见过的团队,一般都会用一个excel表格的方式来记录各个版本的变更,以及发布的客户范围。
这里介绍Zadig平台中的“发布管理 **”模块,**特别是对于2B场景,可能面对很多不同客户,包括不同的定制, 需要一个平台来汇总这些信息,包括
目前,Zadig更多是针对于客户SAAS服务,直接面对线上环境,所以还会有线上基础设施云供应商的配置。
这里其实可以拓展更多,比如对于私有化部署场景,这里交付的可能是部署包,数据库文件等等。
上面从部署发布的概念,不同场景,到案例工具进行了总结,希望能对大家有所启发~
下面归纳了可能影响发布的关键要素。部署发布是软件交付的最后一公里,呼应了产品的发布计划,有序的发布管理和流程,会让价值交付更加清晰透明,取代混乱和低效。
注:部分内容参考网络资料,如有侵权请联系我
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://www.cnblogs.com/FLY_DREAM/p/18002456
内容来源于网络,如有侵权,请联系作者删除!