资讯信息

如何用工具集完成持续交付和运维
发布时间: 2018-02-26    浏览次数:8331次

  前期我们谈了持续集成。当持续集成完成后,会涉及集成的版本做什么?那必然会说到持续交付。

  持续交付,就是时时可持续地编译、测试、评审、部署、发布的一系列活动集。当然这种交付策略可以是定期或是新特性触发,采用一系列自动化工具按照已制定的交付策略快速、准确地执行,从而在质量、效率上大幅提高,成本上大幅降低。

  本篇文章将从需求分析起,涉及设计、编码、测试、预发布、运维等多个环节来示意如何用工具集完成这个持续交付和运维的过程。最后会使用故事地图的展现形式描述各环节、角色、工具与活动的关系。这里还涉及到我们使用的Git Flow,来讲述如何在开发阶段进行版本控制。

  图一是使用自动化工具在SCRUM敏捷框架中进行开发、管理的示意图。具体的管理流程如下:

  1. PO和Team在Confluence上进行故事地图、史诗和故事的分解和分析。对在分析过程中的讨论PO和Team可以在Confluence上展现,并在分析后期对故事地图、史诗、故事等进行评审。评审完成后进行生成WORD文档进行基线管理。

  2. 在Confluence故事分析的基础上,将产品故事在JIRA中生成PB,并经过迭代计划评审会的上半期形成SB,在下半期进行估算后再拆分成一个个迭代任务。

  3. team在实施每个迭代过程中,会召开站立会议,会议中使用JIRA展现进度看板和迭代燃尽图,使故事和任务的进展更加直观,这样可以加深team的熟知度。而且站立会议期间也可以对迭代任务进行认领并跟踪。

  4. 当迭代完成召开迭代评审会时,可以使用JIRA展现产品燃尽图。

  5. 在迭代回顾会上,对管理问题进行讨论、分析并用JIRA进行记录、排序,确定哪些需要在下个迭代中需要改进并以任务形式进行跟踪。

  具体在每个迭代的期间作为一个开发人员如何使用工具进行开发、测试、版本管理,这里以Git工具为例说明开发过程各项活动和版本管理内容(见图二):

图二

  1. 在项目初始期(有的项目将其定为:Sprint 0),将创建Git配置库,并建立master基线并从master中拉出develop分支。

  2. team人员从JIRA上认领任务后,针对自己所要实现的不同特性,拉出多个不同的特性分支,这些特性的分支是在开发者本地。

  3. 开发人员在本地实现特性后,使用TestNG进行单元测试,测试通过后使用Gerrit提交代码评审请求。代码评审人收到申请后对代码进行评审,评审通过,这段代码才能进入到Git 服务器并并入到develop分支。

  4. 当Git有新特性分支的内容合并到develop分支后, Jenkins将进行自动化编译,并使用Clover等静态测试工具进行静态测试并使用Sonar进行规范性检查以及整合出具测试报告

  5. 编译、静态测试、规范检查通过后,将从develop分支并入到release分支,并自动部署在测试服务器上。

  6. 对该版本进行自动化测试,很多自动化测试都是根据自己的产品自行开发的自动测试框架和系统。测试缺陷录入JIRA进行跟踪。

  7. 对缺陷修改的代码提交到Git时将自动与修复的缺陷编码相关联,明确该代码是为修复哪些缺陷而提交的。每次提交前都要执行第3步。

  8. 测试通过后,将release分支合并到master主干上并做基线标识。主干上的产品在质量上应该是可以随时对外发布的。

  以下内容为开发与运维分界线:

  9. 将master主干上的产品代码直接自动部署至预发布环境。这时预发布系统将由运维人员接手,进行部署和验证。这里的验证标准应与后期的实际运营标准一致。

  10. 产品在预发布环境验证通过后,将自动部署(升级)至真实的运营环境。

  以下内容为运维内容:

  11. 对于toB的产品,我们可以使用JIRA对客户开放,将客户反馈的建议、问题记录在系统中,并可以让客户时时看到所提问题的流转状态。

  12. 当对于SAAS部署的产品发生严重故障时(这些故障可以由运营系统自动监测、判断),系统发送信息给相关人员。技术负责人根据事先定义的标准来判定是否回滚。bbs.mypm.net

  下面用故事地图的形式描述持续交付的内容(详见图三):

 

图三

  角色是每个故事中起主导的角色。蓝色线上的故事是最小可行产品(即可使用敏捷方式进行过程改进,MVP是可以先做后根据效果进行完善的最小改进过程),也是以敏捷思维去考虑持续交付和DevOps的内容。



关注安徽招标咨询网微信,随时随地获取最新招标信息

网上报名快速通道仅向VIP会员提供
系统将为您转入相应网上报名页面...
继 续