Practice_Release management 发布管理实践

返回ITIL4理论与实践整体知识体系中文版发布文件汇总
最新消息：本实践中文翻译发布版已经推出，请点击下载。

发布管理实践确保可使用符合组织及其服务使用者之间的组织的政策和协议的服务。 传统上，服务组件对用户是可见的，并且可供用户访问，包括基础结构，软件和文档。随着基础架构和文档越来越数字化，软件管理的方法和方法变得更加适用于这些类型的服务组件。这会影响发布管理实践和其他实践，而这些实践的重点是服务，验证和测试，部署管理和软件开发和管理等软件。 从客户和用户的旅程角度来看，发布管理支持引入和撤销。对于用户而言，此实践可能支持最早的接触点并与服务提供者进行交互。初始引入完成后，此实践支持交付服务更新，这对于实践的成功至关重要。 2.2关键术语和概念 2.2.1发布管理和部署管理 组织应该在组织的价值流和服务关系中为发布和部署管理实践及其角色定义高级方法。 一种方法是将发布和部署活动结合在一起。一旦移至运行的环境，服务组件便可供用户使用。运行环境中一个组件的不同版本共存的情况很少，并且不会持续很长时间。发布和部署活动（以及生产生命周期的步骤）之间没有明确的边界。这种方法通常可以应用于硬件服务组件和大型整体软件系统。 另一种方法适用于Agile数字化环境，现代架构和基于云的数字化解决方案。通过这种方法，可以在发布活动启动之前将新版本的软件部署到运行环境，然后再发布给所有或部分用户。在这种情况下，发布管理活动专注于启用服务的使用，并且可以非常简单和技术化（例如，在存储库中更改XTC64211的状况，以便可以下载）。 （由选定的受众群体）或复杂且以人为中心的内容（例如培训用户以降低风险并增加版本对版本的更改）。 CI/CD和发布管理 敏捷和DevOps中部署的关键概念是持续集成，持续交付和持续部署。MartinFowler[1]将它们定义为： •持续集成通常是指在软件开发环境中集成，构建和测试代码。 •持续交付扩展了该集成，涵盖了生产部署的最后阶段。持续交付意味着内置的软件可以随时发布到生产中。 •持续部署是指通过流程并自动投入生产的更改。这样可以每天进行多个生产部署。持续交付意味着可以进行频繁部署，但是部署的决定要视具体情况而定，这通常是由于企业更喜欢部署的速度较慢。持续部署要求完成持续交付。 在组织中，使用持续部署和管理作为单独的实践发行是普遍且有效的。新版本的软件，文档和数字化基础结构一准备就绪，便会立即部署到实时环境中，然后使用发布管理实践为用户“打开”它们。 如果使用不带持续部署的持续交付，则部署和新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。 最后，如果组织不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。 组织根据生产定义所有产品和服务的发布和部署管理实践的方法。这通常由组织的生产架构（及其跨产品的一致性）和组织对软件生命周期的管理的定义。 2.2.2发布管理的方法，模型和计划如果组织管理不同的架构产品，则可能会定义发布管理的几种方法。一旦为特定的生产达成协议，就可以开发特定于生产的发布管理模型。模型包括但不限于： ●商定的高级方法 ●针对用户的发布对象和用户启用规则 ●发布单位和包装规则 ●推/拉条件 ●验证和客户或用户体验旅程 ●假设，验证和实验的发布使用条款。 生产可能有多个发布管理模型。例如，当使用生产在不同市场上或向业务和单个服务消费者提供服务时。 影响发布管理，模型和实践的开发的因素之一，是生产的组织的控制范围。当组织的控制是完整的生产生命周期（包括开发和部署）时，它在定义发布管理模型方面拥有更大的自由度。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常会引入组织应该考虑的约束。它仍然可以决定是否在其服务中包括更新的组件，但是只能在一定程度上进行决定（直到组件的供应商允许继续使用以前的版本）。 2.2.3发布单位 发布单元可能包括不同类型的软件组件，用户设备以及其他硬件，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户发布的发布注释；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。 某些发布实例可能包含不完整的发布单元，但应作为一个例外：发布紧急（紧急更新），或者过于复杂且已定义了不切实际的发布单元。 重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。版本面向用户，发布的统一定义取决于服务的哪些组件通常会影响用户使用服务和用户体验的能力。 2.2.4推/拉条件 发布管理模型的开发期间做出的决定之一是将服务组件的新版本推向用户，由用户拉动还是将多种方法混合使用。 “推”式方法意味着在未经用户特定许可的情况下为用户启用了新的或更改的服务组件，并且用户必须使用这些版本。相比之下，“拉动”方法为用户提供了新的组件和服务，但是用户可以决定是否更喜欢使用这些新版本，坚持使用较旧的版本或根本不使用服务。 通常，组织不会采用单一方法。相反，他们定义了“拉”或“推”方法更好地工作的条件。注意事项对于内部和外部服务提供是通用的。这包括： ●在用户基座上只有一个版本的好处（可维护性，兼容性） ●允许用户拥有更多自由的好处（更好的图像，灵活的定价选项） ●技术和组织能力来管理运行环境中的多个版本 ●关键更改（删除关键安全脆弱性的更新可能会被“推送”） ●职能型和其他客户的要求（如果实现了必需的新功能，则客户可以要求所有用户进行更新） ●监管要求。 2.2.5假设测试和实验 发布管理可用于验证假设和实验。当具有样本用户受众的组织需求到测试成为假设时，可以将可测试的服务发布到样本组（有时称为治疗组）。这种方法已被大众服务提供商（例如社交网络）广泛使用，但也适用于小型用户组。相关技术包括蓝色/绿色发行版，金丝雀发行版和A/B测试。 这些实验需要其他实践的参与度。这包括但不限于： ●基础设施和平台管理 ●软件开发和管理 ●部署管理 ●架构管理 ●服务台 ●事件管理。 Thereleasemanagementpracticeensuresthatservicesareavailabletouseinlinewithorganization’spoliciesandagreementsbetweentheorganizationanditsserviceconsumers. Traditionally,servicecomponentsarevisibleandaccessibleforusersincludinginfrastructure,software,anddocumentation.Asinfrastructureanddocumentationareincreasinglydigitized,softwaremanagementmethodsandapproachesbecomemoreapplicabletothesetypesofservicecomponents.Thisaffectsthereleasemanagementpracticeandotherpracticeswithsignificantfocusonsoftwaresuchasservicevalidationandtesting,deploymentmanagement,andsoftwaredevelopmentandmanagement. Fromthecustomeranduserjourneyperspective,releasemanagementsupportsonboardingandoffboarding.Forusers,thispracticemaysupporttheveryfirsttouchpointsandinteractionswiththeserviceprovider.Afterinitialonboardingiscomplete,thispracticesupportsthedeliveryofserviceupdates,whichisimportantforthesuccessofthepractice. 2.2KEYTERMSANDCONCEPTS 2.2.1Releasemanagementanddeploymentmanagement Organizationsshoulddefineahigh-levelapproachtoreleaseanddeploymentmanagementpracticesandtheirroleinorganization’svaluestreamsandservicerelationships. Oneapproachistocombinereleaseanddeploymentactivities;oncemovedtotheoperationalenvironment,servicecomponentsbecomeavailabletousers.Co-existenceofdifferentversionsofonecomponentinliveenvironmentisrareanddoesnotlastlong.Thereisnoclearborderbetweenreleaseanddeploymentactivities(andstepsofaproductlifecycle).Thisapproachcanoftenbeappliedtohardwareservicecomponents,andlargemonolithicsoftwaresystems. AnotherapproachisapplicabletotheAgiledigitalenvironment,modernarchitecture,andcloud-baseddigitalsolutions.Inthisapproach,newversionsofsoftwarecanbedeployedtotheliveenvironmentbeforereleaseactivitiesstart,andthenreleasedtoallorsomeoftheusers.Inthiscase,releasemanagementactivitiesarefocusedonenablingserviceusageandcanbeverysimpleandtechnical(suchaschangingapplication’sstatusinarepositorysoitisavailablefordownload byaselectedaudience),orcomplexandhuman-focused(suchastrainingofuserstoreducerisksandincreaseeffectivenessoftheversionchanges). CI/CDandreleasemanagement ThekeyconceptsfordeploymentinagileandDevOpsarecontinuousintegration,continuousdelivery,andcontinuousdeployment.MartinFowler[1]definesthemas: •Continuousintegrationusuallyreferstointegrating,building,andtestingcodeswithinthesoftwaredevelopmentenvironment. •Continuousdeliveryextendsthisintegration,coveringthefinalstagesforproductiondeployment.Continuousdeliverymeansthatbuiltsoftwarecanbereleasedtoproductionatanytime. •Continuousdeploymentreferstothechangesthatgothroughtheprocessandareautomaticallyputintoproduction.Thisenablesmultipleproductiondeploymentsaday.Continuousdeliverymeansthatfrequentdeploymentsarepossible,butdeploymentdecisionsaretakencasebycase,usuallyduetobusinessespreferringaslowerrateofdeployment.Continuousdeploymentrequiresthatcontinuousdeliveryisbeingdone. Inorganizations,usingcontinuousdeploymentmanagementforreleasesasaseparatepracticeiscommonandeffective;newversionsofsoftware,documents,anddigitalinfrastructurearedeployedtoliveenvironmentsassoonastheyareready,andthenreleasemanagementpracticeisusedto‘switchthemon’forusers. Ifcontinuousdeliveryisusedwithoutcontinuousdeployment,deploymentandnewandchangedreleasecomponentsmaybesynchronizedandmanagedasasinglestepinrespectivevaluestreams. Finally,ifanorganizationdoesnotusecontinuousdeliveryorcontinuousdeployment,releasemanagementactivitiesaremorelikelytobecombinedwithdeploymentmanagement. Organizationsdefinetheapproachtoreleaseanddeploymentmanagementpracticesforallproductsandservices,orperproduct.Thisisusuallydefinedbyorganization’sproductarchitecture(anditsconsistencyacrossproducts),andbyorganization’sapproachestomanagementofsoftwarelifecycle. 2.2.2Releasemanagementapproaches,modelsandplans Ifanorganizationmanagesdifferentarchitectureproducts,itislikelythatseveralapproachesforreleasemanagementwillbedefined.Aproduct-specificreleasemanagementmodelcanbedevelopedonceanapproachedisagreedforaspecificproduct.Thismodelincludes,butisnotlimitedto: ●agreedhigh-levelapproach ●targetuseraudienceofreleasesandrulesforuserenablement ●releaseunitsandpackagingrules ●push/pullconditions ●verificationandacceptancecriteria ●termsandconditionsofreleaseusageforhypothesisverificationandexperimentation. Itispossibletohavemorethanonereleasemanagementmodelforaproduct.Forexample,whenaproductisusedtoprovideservicesondifferentmarketsortobusinessandindividualserviceconsumers. Oneofthefactorsthatisaffectingthedevelopmentofthereleasemanagementmodelandthepractice,istheorganization’sscopeofcontroloftheproduct.Whenorganization’scontrolthefullproductlifecycle,includingdevelopmentanddeployment,ithasmorefreedomindefiningreleasemanagementmodels.Incontrast,iftheorganization’sservicesarebasedonthird-partycomponents,orthedevelopmentanddeploymentaremanagedbyasupplier,itusuallyintroducesconstraintsthattheorganizationshouldconsider.Itstillmaybeabletodecidewhethertoincludeupdatedcomponentsinitsservices,butonlytoacertainextent(untilcomponents’vendorallowstokeepusingpreviousversions). 2.2.3Releaseunits Releaseunitsmayincludedifferenttypesofsoftwarecomponents,userequipment,andotherhardware,documents.Releaseunitfortheinitialreleaseofaservicetonewusers,canbedifferentfromreleaseunitforupdatesofthesameservice.However,somecombinationsofcomponentsmayberecommendedorevenmandated.Forexample,everyupdateshouldincludepublishedreleasenotesforusers;however,insomecases,userequipmentshouldbeupdatedafteritsinitialreleasetousers. Somereleaseinstancesmayincludeincompletereleaseunits,butshouldbeanexception:eitherareleaseisurgent(emergencyupdate),ortoocomplexandanimpracticalreleaseunithasbeendefined. Itisimportanttorememberthatareleaseunitmaybedifferentfromadeploymentunit,whichdefinescomponentsthatarenormallydeployedtogether.Releasesareuser-facing,andthedefinitionofareleaseunitedependsonwhichcomponentsofserviceaffectusers’abilitytousetheserviceanduserexperienceingeneral. 2.2.4Push/pullconditions Oneofthedecisionsmadeduringthedevelopmentofthereleasemanagementmodeliswhethernewversionsofservicecomponentswillbepushedtousers,pulledbyusers,ortherewillbeamixoftheapproaches. A‘push’approachimpliesthatneworchangedcomponentsofservicesareenabledforuserswithouttheirspecificconsent,andusersareobligedtousetheseversions.Incontrast,the‘pull’approachmakesnewcomponentsandservicesavailabletousers,butuserscandecidewhethertheypreferusingthesenewversions,sticktoolderones,ornotusingtheserviceatall. Typically,organizationsdonotapplyasingleapproach;instead,theydefineconditionswherethe‘pull’or‘push’approachwouldworkbetter.Considerationsarecommonforinternalandexternalserviceprovision.Thisincludes: ●thebenefitsofhavingasingleversionacrosstheuserbase(maintainability,compatibility) ●thebenefitsofallowinguserstohavemorefreedom(betterimage,flexiblepricingoptions) ●technicalandorganizationalabilitytomanagemultipleversionsinaliveenvironment ●criticalchanges(anupdateremovingcriticalsecurityvulnerabilityislikelytobe‘pushed’) ●functionalandothercustomer’srequirements(ifarequirednewfunctionalityisimplemented,customersmaymandatetheupdateforallusers) ●regulatoryrequirements. 2.2.5Hypothesistestingandexperimentation Releasemanagementmaybeusedtovalidateahypothesisandanexperiment.Whenanorganizationneedstotestahypothesiswithasampleuseraudience,testableservicesmaybereleasedtosamplegroups(sometimescalledtreatmentgroups).Thisapproachiswidelyusedbyprovidersofmassservices,suchassocialnetworks,butalsoappliedtosmallusergroups.Relatedtechniquesincludeblue/greenreleases,canaryreleases,andA/Btesting. Theseexperimentsrequiretheinvolvementofotherpractices.Thisincludes,butnotlimitedto: ●infrastructureandplatformmanagement ●softwaredevelopmentandmanagement ●deploymentmanagement ●architecturemanagement ●servicedesk ●incidentmanagement. 申明： 本文档由长河（微信achotsao）在机译的基础上经初步整理而成，精细化翻译工作正由IT运维管理社区组织的ITIL专家团队进行之中，预计将于2020年年底之前全部完成。需要下载最终翻译版本请关注微信公众号：IT运维管理社区，或访问or。
IT运维管理社区专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含中文翻译版本）时需完全遵守Axoles和TSO所申明的所有版权要求。