[转载]DevOps建立全生命周期管理

全生命周期管理(ALM)领域作为企业DevOps实践的总体支撑,应该说是DevOps领域中最为重要的实践领域,也是所有其他实践的基础设施。现在很多企业都非常重视CI/CD自动化工具的引入和推广,但是对ALM的建设的重视程度并不够。CI/CD的火爆很大程度上是被Docker和DevOps的热潮带动的,但CI/CD自动化只是提升团队效率的一个环节,如果没有ALM工具的支撑,CI/CD也只是空中楼阁,无法起到整体优化团队工作效率的作用,甚至局部的效率提高还会造成团队的不适应甚至抵触。如果管理者看不到自动化所产出的价值提升,团队感受不到自动化所带来的效率改进,这一切的问题都应该归根于企业没有建立端到端的研发数据链,数据不打通,问题的反应永远只是局部的,无法从问题的表象跟踪到问题的根源。《凤凰项目》中所提到的DevOps三步工作法的第一步:建立全局观;其实是后续的建立反馈和持续改进的基础。CI/CD自动化在DevOps中所起到的作用更多的是加快反馈速度,但在没有建立全局观的情况下一味的进行反馈其实是没有作用的。

就研发数据链来说,下图所展示的《软件研发管理过程全景》中每个元素以及元素之间的链接就是ALM平台所最关注的重点。只有建立了完整的研发数据模型,有了这些关系,我们才能从整体上对研发效率进行评估,找到瓶颈,进而改进。建立这个模型的过程其实就是DevOps三步工作法的第一步:建立全局观。

(说明:以上的全景图是基于敏捷开发模式的,在传统瀑布模式下,中间的项目计划一般是从“架构模型”过来的,而不是从“条目化需求”过来的)

在全生命周期管理实践中,工具的使用是非常重要的一环。我时常把ALM系统比作研发的ERP,而实际上就是这样一种关系,ALM平台就是研发的信息系统。在所有的ALM系统中,跟踪都是最基本的模块,比如:VSTS/TFS中的工作项跟踪,或者Atlassian产品中的Jira工具都是专注于这个领域的成功产品。但是我们也应该注意到上图中除了对事务或者内容的跟踪以外,我们还需要把代码,用例,版本和环境也作为跟踪的一部分。要做到这一点,工作跟踪与配置管理,与自动化系统的数据链路打通就变成了一种必须。

在这种场景下,一体化的工具(如:微软的VSTS/TFS)就发挥出了它的优势,因为内置了包括工作跟踪,测试管理,代码库(GIT)和自动化系统(CI/CD);对于以上全过程的数据采集就变得易如反掌,同时配合后台的企业级数据挖掘和分析引擎,让研发数据链的建立,数据清洗和挖掘工作全自动化,不再需要另外投入精力从不同的系统中抓取数据并进行ETL聚合等操作。而使用相互独立的过程跟踪(如JIRA, redmine),配置管理(如SVN,GitHub/GitLab,BitBucket),测试管理(如:QC, TestLink),缺陷管理(如:Bugzilla)和自动化(如:Jenkins)工具,要建立完整的研发端到端数据链就必须另外建设独立的数据挖掘和分析平台;这部分工具不仅投资巨大,而且难度很高。这后一种场景在企业信息化建设中也是一种常见的误区,一般称为烟囱式建设或者信息孤岛效应,大多数企业管理者都会希望采用各个领域最专业的系统来建设,最后发现每个领域你都用不到那个系统功能的20%,还要再花费巨大的时间和资金投入去进行系统集成和数据打通。

在研发领域,能够把管理者最关心的数据从团队成员的指尖送到管理者的面前,其实是这些系统最重要的功能之一,如下图:

类似以下这张报表,如果没有完整的研发数据链和数据模型,是很难做到的

 

我们一般称此报表为:项目/产品交付进度,它不仅仅展示了事务工作的进度(开发进度一栏),同时也在每个需求维度上展示了质量情况(测试用例通过率和bug修复率)。这样对于管理人员来说,你无需知道细节就可以对某一特定需求的交付能力进行判断。

 

为了生成以上这张报表,我们需要聚合至少3类数据

1. 不同层级需求上的进度情况:需求管理过程中,为了能够给不同的角色进行分工,或者区分不同类型或者粒度的需求,我们一般都会将需求组织成树形结构;并在最底层节点上挂接开发任务并分配给团队成员;团队成员在任务粒度上的进度反馈需要一层一层累加到最终用户可见的需求上;这个数据模型的建立主要通过工作跟踪模块来完成,数据分析的建立则需要经过一定ETL处理的数据仓库配合。

2. 测试进度:测试管理涉及测试事务管理和测试内容管理两个部分,事务管理的是人员的工作量和进度,而内容管理的是产出的具体测试用例和执行结果。实际工作中,我们必须能够同时管理这2个维度的工作,同时将测试内容的结果反馈到具体的需求上,这样对交付才有作用。这部分的数据通过ETL进行处理时必须能够和前面的需求粒度产生数据联系。

3. 缺陷进度:缺陷一般是测试产出或者用户(包括团队成员)的反馈,包括修复的情况。同样,这部分数据也需要在ETL的时候和需求粒度建立联系。

另外一个研发数据挖掘和分析的很有意思的应用是Code Lens,如下图:

通过整合代码库历史记录与工作项跟踪信息,可以在开发人员编辑代码的同时在后台分析出当前的代码块在历史上曾经出现过哪些问题/bug,帮助开发人员定位问题。

我们在研发管理上往往陷入一个误区,就是让具体做事情的人(程序员、测试人员等)觉得他们所做的任务更新,代码提交都是给别人做的;自己完全体会不到任何好处;久而久之,就失去了主动性,认为管理的事情跟自己无关,采取不配合甚至抵触,更有甚者则提供假数据蒙混过关。这其实不是开发人员的问题,造成这种状况的原因是我们没有让开发人员从自己所提供的数据中获取价值。如果我们能够提供更多类似Code Lens这种开发辅助工具,开发人员一定是乐于参与其中的。我们在DevOps中常说要打破部门壁垒,建立协作;这些不能只靠做游戏,我们还需要为流水线中的每个角色提供实打实的价值反馈,才能让大家真正成为一个整体。

简单总结一下,全生命周期管理平台数据分析的价值有二:

  • 第一:为管理者提供更多的Insight,让所有的细节串接成为研发全景图,提升管理者对实际状况的把控能力。只有看到才能评估,只有评估才能管理
  • 第二:为开发人员提供更多的Insight,让流水线中的每个环节都能获得对他们有价值的反馈。只有反馈了价值才有正能量,只有正能量才能形成协作

因此,我们决定从2017年5月份开始维护 “VSTS/TFS功能发布时间轴”,这个页面将跟随VSTS的三周发布频率,定期更新,同时对新发布的功能进行简要介绍。希望能够帮助广大企业和开发团队及时了解这一工具的最新动态,持续优化自己的DevOps实践。

我曾经为多家大型企业实施过微软的VSTS/TFS全生命周期管理平台,这些企业最看重的一点其实就是是TFS在研发数据分析上所体现的开箱即用能力。这些年,微软TFS(包括在线的VSTS)的版本更新越加频繁(从每2年一个版本提升到每3周一个版本),我们的客户非常关心这些新特性的发布情况,同时我们自己也需要不停的跟进这些新特性以便给客户提供最优化的方案。

页面地址:http://devopshub.cn/vsts-tfs-feature-timeline/,也可以点击本文下部的阅读原文进入页面。

这个页面分为2部分,同时显示VSTS在线版的发布时间和TFS企业版的发布版本号,中间的特性列表中包含指向这些功能介绍的链接。我们会逐步将这些功能的介绍链接翻译成中文,让国内的团队能够第一时间了解这些功能的变化。

1.开发中的功能列表

2.已经发布的功能列表

这次,我们还同时发布了2017年5月11日的VSTS迭代更新说明
http://devopshub.cn/2017/05/19/vsts-update-may-11-team-services/

这个页面的发布要特别感谢我们团队的90后程序员Caden,在短短1周之内就完成了页面的搭建和翻译工作,年轻人就是厉害!

请大家持续关注我们的微信号:devopshub,在VSTS/TFS栏目中我们会持续更新这个页面。

谢谢。

原文:《DevOps三步工作法的第一步:建立全生命周期管理能力

时间: 05-23

[转载]DevOps建立全生命周期管理的相关文章

项目全生命周期管理

原文地址:https://www.cnblogs.com/-levi/p/11401955.html

助力绵阳市商业银行,打造高效项目生命周期管理平台

金融市场捷报连连,近日,TechExcel公司再次凭借产品和服务实力直签下绵阳市商业银行,打造项目全生命周期管理平台.DevSuite研发与项目管理平台为绵阳市商业银行员工提供了一套必不可少的信息化工具,大大提升研发管理效率. 绵阳市商业银行(绵阳市商业银行股份有限公司)是国有控股地方商业银行,成立于2000年9月,是中国(绵阳)科技城唯一一家国有控股法人金融机构.成立至今,绵阳市商业银行秉承"服务地方.服务中小"的企业宗旨,全力打造一流中小企业金融服务机构,不断开创科学发展新局面.2

Jasper:用户指南 / 设备 / 生命周期管理 / SIM 卡状态

ylbtech-Jasper:用户指南 / 设备 / 生命周期管理 / SIM 卡状态 1.返回顶部 1. SIM 卡状态 每个设备都有一个状态,决定了它能否在网络上建立数据连接,并且会影响设备是否计费.下图显示了一个典型的设备生命周期.在遵循某些限制的情况下,您可以将设备从一个状态转换到另一个状态. 设备在每个状态下可用的服务由与该设备的通信计划相关联的通信配置文件所控制.Control Center 将"关闭"通信配置文件应用到非活动的设备,而将"开启"通信配置

tomcat系列分析之生命周期管理初始化动作

tomcat中有很多组件,要对这些组件进行生命周期的管理非常困难,tomcat中采用的是抽象出一个生命周期管理接口,然后所有的组件都实现该接口,当父组件启动时,同事负责将子组件启动起来,从而完成整tomcat的初始.启动.结束等动作. 来看下tomcat启动的过程,首先构造Bootstrap类,调用其中的init方法,完成类加载器的初始化,方便后面加载类使用,然后调用其中的load方法,实际上tomcat真正的启动动作是由Catalina类完成的.而这其中在BootStrap中调用Catalin

6、Khala的登录生命周期管理

khala能够对设备进行生命周期管理,并提供了与生命周期相关的接口,用户只需在具体的设备类型实现类中重写这些生命周期接口,即可享受khala对于生命周期管理的同时定制与业务相关的操作.具体接口解释如下: onLoginCheckMsg(): 进行登录检查,在此可以通过查询DB等方式检查登录设备账号是否合法,可以为连接设备设置设备ID(此ID必须唯一,将被视为设备key,若出现重复将执行onLoginFailureMsg,若未设置将以临时ID值作为ID key),若账号检查失败,设置失败回复消息并

Spark发行笔记8:解读Spark Streaming RDD的全生命周期

本节主要内容: 一.DStream与RDD关系的彻底的研究 二.StreamingRDD的生成彻底研究 Spark Streaming RDD思考三个关键的问题: RDD本身是基本对象,根据一定时间定时产生RDD的对象,随着时间的积累,不对其管理的话会导致内存会溢出,所以在BatchDuration时间内执行完RDD操作后,需对RDD进行管理. 1.DStream生成RDD的过程,DStream到底是怎么生成RDD的? 2.DStream和RDD到底什么关系? 3.运行之后怎么对RDD处理? 所

viewpager中fragment的生命周期管理

viewpager中fragment的生命周期管理 - i_bobby - 开源中国社区 调试fragment的时候发现一个莫名其妙的事情,viewpager中包含4个fragment,其中第一个和第三个fragment是要联网取得数据的,如图: 界面刚进去的时候显示第一个fragment,通过log信息,我发现two fragment竟然"偷偷"走了一遍的生命周期!着实把我震惊了! 然后我滑动到two,发现第三个也"偷"了一遍生命周期,也就是说,手机在显示第二个不

Spark发行版笔记10:Spark Streaming源码解读之流数据不断接收和全生命周期彻底研究和思考

本节的主要内容: 一.数据接受架构和设计模式 二.接受数据的源码解读 Spark Streaming不断持续的接收数据,具有Receiver的Spark 应用程序的考虑. Receiver和Driver在不同进程,Receiver接收数据后要不断给Deriver汇报. 因为Driver负责调度,Receiver接收的数据如果不汇报给Deriver,Deriver调度时不会把接收的数据计算入调度系统中(如:数据ID,Block分片). 思考Spark Streaming接收数据: 不断有循环器接收

SView航天全生命周期解决方案

在产品的全生命周期管理中,越来越多环节需要产品的数据协同,在这其中以3D模型为数据基础,向各阶段人员提供一致的产品和项目信息,达到更好的沟通和协作,模拟真实性以便让各方更高效.更精确的生产制造. 需求描述? 卫星.运载火箭等航天器结构越来越复杂,三维设计模型越来越大,大模型的显示.浏览和使用越来越困难:? 现场人员在航天器操作和检验时浏览卫星模型和电子化表格记录非常不便,需要加强现场质量数据表格化记录的规范性.结合航天院所的实际应用,SView提供了从设计研发.工艺规划.生产制造.质量检验.维修