全生命周期管理领域做为企业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实践。

 

原文来自：http://www.yunweipai.com/archives/18136.html

本文地址：https://www.linuxprobe.com/devops-build-management.html编辑员：郭建鹏，审核员：逄增宝