内容


助力 Rational Team Concert 落地,第 1 部分

企业级研发管理平台的规划

Comments

系列内容:

此内容是该系列 4 部分中的第 # 部分: 助力 Rational Team Concert 落地,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:助力 Rational Team Concert 落地,第 1 部分

敬请期待该系列的后续内容。

背景和术语

关于 CLM 和 Jazz

基于 Jazz 平台的 IBM Collaborative Lifecycle Management(简称 CLM)解决方案为企业用户提供了一个覆盖软件研发各个环节、支持异地分布式团队的集成开发环境(如图 1)。本文详细介绍的 Rational Team Concert(简称 RTC)是基于 Jazz Team Server(简称 Jazz)上名为 Change and Configuration Management(简称 CCM)的一个应用(中译为"变更和配置管理"),属于 CLM 解决方案的一个产品模块,服务于软件研发体系的开发环节,提供团队协作、项目管理、配置管理(Jazz SCM)、构建管理(Jazz Build Engine,简称 JBE)等功能模块。除了 RTC 以外,CLM 解决方案还提供 Rational Quality Management(简称 RQM)产品模块,服务于测试管理环节;提供 Rational DOORS Next Generation(简称 RDNG),服务于需求管理环节。

图 1.基于 Jazz Team Server 的 CLM 解决方案

Jazz 平台还定义和规范了 RTC,RQM,RDNG 和其他自定义应用或第三方应用软件之间数据的关联和通信,还提供了项目管理(Project Admin),流程配置(Process Configuration),报告(Report),仪表盘(Dashboard)等底层功能框架。RTC,RQM,RDNG 都是基于这些框架,进行开发和扩展各自功能和交互界面的,因此 IBM CLM 解决方案即为面向企业的研发管理平台落地方案(如图 2)。

图 2.CLM 解决方案是面向企业的研发管理平台落地方案

企业级研发管理平台

不同企业在业务、规模、历史等各方面都不尽相同,其研发体系也会有各自发展和改进的路径,但随着业务从少到多、研发体系从小到大、产品从简单到复杂,流程从无序到有序,从管控的角度看,都有对研发数据共享和分析的强烈需求。那么对研发过程的流程控制、数据记录和分析等行为,就需要统一的研发管理平台来控制和共享。同时,企业级研发管理平台更加强调基于多组织架构,结合门户系统的分布式应用集成策略,实现统一平台层面的权限控制和数据整合。

如果把 CLM 解决方案作为面向企业的研发管理平台落地方案。这其中,服务于开发环节的 RTC 就是 CLM 解决方案中地位最重要、功能最丰富、适用范围最广泛的研发管理产品。研发团队及其涉及的各种角色(如开发、测试、架构,Scrum Master,Product Owner,PM 等)会把 RTC 当作研发过程管理和协作工具,支持多种形式(如 Scrum,SAFe,Kanban 等)的敏捷开发;通过多种类型的工作项覆盖和支持任务管理、需求管理、缺陷管理和项目(计划)管理;通过多种形式的自定义方法,灵活配置工作项的关联、约束和过程流转;通过 Plan(Views),Dashboard,Report 等展示形式,实时监控和管理工作项,从不同角色的视角展示和预警项目在不同阶段的状态。

同时,开发和配置管理团队如果选择使用 RTC 自带的 Jazz SCM 功能模块,可把 RTC 当作源代码管理工具;开发和构建团队如果选择使用 RTC 自带的 JBE 功能模块,可把 RTC 当作持续集成和部署工具;在 RTC 上流转和保存的研发数据,可以满足不同角色分享和共用,同时基于这些数据的分析,是研发组织和管理层最看重的。由此可见,引入并使用 RTC 是企业级研发管理平台落地的基础。

RTC 落地的范畴

对致力于打造企业级研发管理平台的决策者和推动者来说,要明确:"RTC 落地的最终目的是要推动 CLM 解决方案实现研发体系升级,对研发过程和数据的整合和分享:过程要统一、可控,数据要实时、透明。"

因此,RTC 落地过程并不能等同一个小型研发团队引入满足某种需求的工具那么简单,需要划分阶段和范围。从落地涉及到的工作看,可分以下大类:

  1. 搭建和维护 RTC 生产环境,以及其他配套环境。
  2. 了解研发体系和具体项目的过程和现状,计划 RTC 落地内容和顺序。
  3. 规划与 RTC 落地同时进行的过程改进,对原有流程和工具进行取舍,迁移数据。
  4. 培训 RTC 功能,推动团队自行参与、使用、反馈和优化,达到引入成熟度螺旋状提升。
  5. 基于需求,持续改进 RTC 对研发过程的定义,持续交付 RTC 和 CLM 新能力。

上述工作,我们可以归类于规划范畴、部署范畴、运营范畴和运维范畴。因此,在《助力 Rational Team Concert 落地》系列文章中,笔者力图从规划、部署、运营与持续交付、运维与演进等多个维度对 Rational Team Concert 落地的过程进行讨论,并通过对实际案例的分析、对操作步骤的详解,帮助致力于研发管理平台建设的决策者、推动者、使用者和参与者更好的认识和利用 RTC,并对引入和实施其它企业级应用的落地路径有所参考。

场景介绍

本文引入一个模拟的企业场景,其中下面内容体现了当时研发体系的现状:

  • 研发组织有多个研发团队,多个产品线;
  • 每个产品线在源代码管理、持续集成、缺陷跟踪、测试管理等环节都使用不尽相同的工具,且自行维护;
  • 每个团队在研发过程中的开发、测试、变更、发布、配置管理等流程和管理风格都有所差异;
  • 对于项目管理、需求管理等环节的数据,基本停留在项目经理的 MS Project 中。虽然有部分团队使用 Scrum 敏捷模式做研发,但停留在"白板站会"形式上,数据需要项目助理同步保存在 MS Excel 中进行统计和报告;
  • 研发团队目前都在本地,但随着业务发展,未来几年计划在国内外多地成立研发中心。

管理层已认识研发管理遇到的瓶颈,希望通过引入企业级研发管理平台帮助研发体系上一个台阶。经过前期对 RTC 和 CLM 解决方案的调研,希望 RTC 尽快落地、试用,并对平台规划和部署提出了一系列要求。

整体要求

  • 统一平台
  • 易扩展、异地部署
  • 易维护、易拆分
  • 支持高可用
  • 支持灾备
  • 尽快落地

迁移要求

  • 基于整体需求、现有硬件资源和 RTC 功能,确定迁移范围和预案
  • 确保研发团队和成员稳妥、有序、渐进的转变工具平台,不影响研发进度
  • 确保原工具及其研发数据完整迁移到新工具平台

集成要求

  • 基于整体需求、现有硬件资源和 RTC 功能,确定集成范围和预案
  • 确保在用原工具及其研发数据整合到新工具平台

硬件资源

目前对 RTC 环境的部署,IT 部门没有新硬件的预算,不能进行新的软硬件资产的规划和部署。IT 部门只提供 2 台 Power Linux 硬件,少量存储。如果需要,还可以提供 1 到 2 个基于 Power7 硬件上的 Power VM(AIX),可连接存储和带库(如图 3)。

图 3.可用硬件列表

软件资源

RTC 和 CLM 解决方案最新版本为 6.0.4,可以通过 jazz.net 网站获取最新的 Rational Team Concert(https://jazz.net/downloads/rational-team-concert)和 Collaborative Lifecycle Management(https://jazz.net/downloads/clm)安装包、SDK 代码、集成工具等。如果已购有客户号,可以从 Support 站点(Passport Advantage Online for customers)直接获得包括 WAS 和 DB2 的完整安装套件(如图 4)。

图 4.CLM 安装套件(部分安装包)

环境规划

生产环境

RTC 生产环境用于正式交付 RTC 服务,保存研发过程各类型数据。因为 RTC 本身是基于 Jazz 平台的一个应用,所以它可以选择不同的应用服务器和数据库服务器。其中快速安装几乎不需要任何额外安装和配置就能得到 RTC 环境,数据库使用默认的 Derby,应用服务器使用默认的 Tomcat(6.0 以后附带 Liberty),但真实的企业应用场景在集成、灾备、高可用等方面对生产环境都有更高的要求,因此官方建议生产环境部署在 WebSphere Application Server 应用服务器(简称 WAS)和 DB2 数据库服务器上,并在 CLM 5.0 和 6.0 安装套件中提供了支持不同平台(Windows x86-32/64,Linux x86-32/64,Linux on Power, AIX on Power 等)的 WAS/IHS v8.5.5 和 DB2 v10.5 的安装包。

配套环境

除了生产环境,另外规划和部署相同或相近的 RTC 环境作为配套环境,用以满足运营和运维需求,并保证生产环境的平稳运行。

  • 试用环境:供研发团队试用的 RTC 环境;试用环境试用默认的应用服务器和数据库,快速搭建,简单配置即可交付;试用期间的配置和数据可以有选择的迁移到生产环境。
  • 备用环境:保持和生产环境配置一致,并定期同步数据;在主机房发生故障或生产环境因故障宕机情况下,快速切换到备用环境;也可作为准生产环境,用于测试配置的变化或软件的升级验证。
  • 沙箱环境:使用虚拟机搭建的最简安装环境,用于培训、测试、集成等。
  • 灾备环境:在主机房发生故障或生产环境硬件损毁时,在新划拨的硬件或虚拟环境上进行恢复操作;平时预留一定资源,用于定期实施灾难恢复演练。

硬件虚拟化

鉴于硬件资源有限,将 Power Linux 硬件做虚拟化设置,使用 IVM 创建和维护多个 Power VM,用于生产环境和配套环境等(如图 5)。

图 5.Power Linux IVM 管理平台

硬件分配

基于 RTC 和 Jazz 平台自身功能特性和部署要求,以及 IT 部门目前提供的硬件资源,我们对硬件进行了环境规划(如图 6),用以满足企业对研发管理平台的需求。

图 6.硬件资源使用列表

整体架构

通过分析企业对研发管理平台的整体要求,我们对规划和部署制定了相应的方案,如下:

  • 通过改造和使用现有 openLDAP 服务器和 LDAP 数据,统一进行身份验证和用户管理
  • 通过设置 IHS 方向代理服务器,保证研发管理平台使用统一的 URI 域名入口,既满足入口统一、管理统一,也满足扩展添加异地节点的要求,不影响用户使用体验
  • 通过预先部署 CLM 解决方案的 RQM 和 RDNG 等应用,便于 RTC 落地后从研发管理快速扩展到测试管理和需求管理环节
  • 通过 IHS、DB2、RTC 多节点与 JTS 应用的配合使用,便于后台环境维护和数据迁移,满足快速拆分和数据隔离的要求,减少对用户使用的影响
  • 基于现有软硬件资源,使用 Power VM 搭建一套生产环境,搭建另一套备用环境用于应用层面的高可用
  • 基于现有硬件和存储资源,通过对 DB2 服务器的设置,提高数据层面的高可用
  • 基于现有硬件和存储资源,使用带库和存储进行日常备份
  • 基于 RTC 现有的迁移、集成方式和工具,和研发团队确认后,迁移或集成原有工具和数据
  • 为满足尽快落地的要求,可以先行搭建和部署试用环境,供研发团队培训、熟悉、使用和反馈;同时搭建和部署生产环境,明确交付时间;如在试用后,需要迁移试用环境数据,提前做好迁移调研和预案。

单点架构

所谓单点架构,可以理解为一组环境,包括 WAS 应用服务器,IHS 服务器和 DB2 数据库服务器三台机器。这是依据生产环境配置标准,以及应用与数据分离的原则进行划分的。CLM 安装程序需要安装在 WAS 所在的机器,并在 WAS 上部署 CLM 提供的 JTS(即 Jazz 平台)、CCM(即 RTC)、QM、RM 四个应用。之后,CCM、QM、RM 应用正常注册在 Jazz 平台后,提供 RTC、RQM、RDNG 的服务。在注册过程中,这些服务完成与 LDAP 和 DB2 关联。其中,WAS 及其上的 JTS 应用都会集成 LDAP 进行身份验证和用户管理。源代码管理工具(如 GitLab)和构建工具(如 Jenkins 等)的集成取决于研发团队的需求,需要在 RTC(CCM 应用)上创建的项目区域(Project Area)后进行集成或关联(如图 7)。

图 7.CLM 单点架构

多点扩展

我们把上述单点架构(一组环境)理解为一个 CLM 节点,在这个节点上提供了基于 Jazz 平台的 RTC、RQM、RDNG 三种服务。同时,一个 CLM 节点可以只部署 JTS 应用,作为 Jazz 平台;其他多个 CLM 节点也可以分别部署 CCM、QM、RM 应用或只部署其中一个应用,注册到 Jazz 平台后即可作为 RTC、RQM 和 RDNG 服务对外发布。

这些分布式服务可能来自本地,也可能来自异地,需要在注册 Jazz 平台过程中就赋予统一的 URI 入口。这 URI 就来自反向代理服务器的定义,使运行在不同机房、不同机器、不同端口上的应用看起来由一个源头提供。这样的好处在于:

  • 如果代理服务器后面的异构应用出现变化,如修改机器名、修改端口、应用迁移到其他机器,并不影响用户使用原有 URI 访问变化后的服务
  • 如果在代理服务器后增加或减少 CLM 节点和服务,不影响用户正常使用未变化的服务
  • 如果对使用研发管理平台的不同团队或产品线,有数据隔离或应用隔离的要求,那么不同团队使用不同 CLM 节点,避免物理层面或逻辑层面使用相同软硬件资源。代理服务器成为不同 CLM 节点的门户。
  • 由于 CLM 本身没有提供项目区域(Project Area)级别的迁移功能,如果要把项目区域从一个 CLM 节点迁移到另一个 CLM 节点,目前只能做二次开发才能实现。因此,我们在做部署规划阶段充分考虑到这点,尽早在部署阶段作数据隔离(如一个 CLM 节点只服务一个产品线或团队),则可以减少项目区域迁移的复杂度,即只做 CLM 节点的迁移就可以了。

注意:CLM 节点只表示它部署 CLM 哪些应用、提供哪种服务,不特指应用部署在哪个 WAS 应用服务器上,使用哪个 DB2 数据库服务器;不同 CLM 节点的应用可以通过创建不同的 WAS Profile,部署在同一个 WAS 应用服务器上,也可以部署在不同的 WAS 应用服务器上;不同 CLM 节点的数据可以使用不同 DB2 数据库服务器创建的 DB2 数据库,也以使用同一个 DB2 数据库服务器,在上面创建不同节点(应用)对应的 DB2 数据库。

IBM 官方推荐的生产环境拓扑架构(如图 8),JTS、CCM 等应用分别部署在自己的服务器上,但他们都集成到 IHS 反向代理服务器后,由统一 https://clm.example.org 发布;JTS 应用(Jazz 平台)对 CCM、QM 等应用完成注册后,统一提供可关联的 RTC、RQM、RDNG 服务;同时各个应用的数据都存储在同一数据库中,便于管理和维护。

图 8.CLM 部署拓扑架构(官方建议)

来源:https://jazz.net/wiki/bin/view/Deployment/RecommendedCLMDeploymentTopologies5

因此,我们规划的单点架构除了运行自身 CLM 节点功能外,还可以充当 Jazz 平台的控制节点,接受本地或异地其他 CLM 节点的注册后,以统一的 URI 入口对外提供其服务(如图 9)。随着企业业务和规模的变化,这个架构允许 CLM 节点的扩充和缩减。

图 9.多点扩展架构

拆分和迁移

如果企业组织框架发生变化,统一的企业研发管理平台需要拆分成本地和异地两个,且要求做到数据和应用双层隔离,那么需要拆分操作(如图 10):

  1. 搭建异地 DB2 数据库服务器,迁移 ccm2 对应的数据,确保数据层面的物理隔离
  2. 搭建异地 IHS 反向代理服务器,确保应用入口层面的隔离
  3. 在异地 WAS 应用服务器上部署 JTS 应用,将原只提供 RTC 服务的异地 CLM 节点改造成自带 Jazz 平台的 CLM 节点,同时迁移原 JTS 对应的数据到异地 DB2 数据库服务器
  4. 在原 Jazz 平台(JTS 应用)注销 CLM2 节点,在异地新 Jazz 平台重新注册 CLM2 节点
图 10.拆分迁移

注意:用于 ETL 的数据仓库 dw,License,email 等属性,以及所有 LDAP 用户都要在 Jazz 平台(JTS 应用)上进行管理,并向其他注册 CLM 节点同步。如果这些数据或工具也要拆分,需要对新 Jazz 平台相关参数重新设置。

高可用架构

从软件层面看,CLM 安装套件只提供 DB2 Work Group 版,没有 DB2 企业版提供的高可用 DRHA 功能模块;同时 CLM 安装套件只提供 WAS Base 版,没有 WAS ND 版提供的集群相关模块;因此,CLM 本身并不具备基于外部数据库和应用服务器的、应用一级的高可用特性。从硬件层面看,基于 Power7 硬件挂载外部存储的 Power VM AIX,可靠性相对较高;而 Power Linux 硬件,没有配置外部存储,只使用本地硬盘并虚拟化出来的 Power VM RHEL,可靠性相对较低。

因此,我们只能基于 CLM 安装套件提供的 WAS 和 DB2,从部署层面有限的满足高可用需求,例如比较容易实现的主备机模式(如图 11):

  • 搭建生产环境的同时,再搭建完全相同的备用环境,对生产环境和备用环境进行定时同步;通过同步的频率和范围进行权衡和定义,来满足不同层级高可用的需求
  • 数据库层面,通过在生产环境的定时备份导出,传输到备用环境后进行定时恢复来实现
  • 应用层面,通过对 IHS 反向代理、WAS 应用服务器和 CLM 重要配置目录或文件的同步来实现
  • 监控 CLM 应用运行状态,如果异常,通过变更反向代理设置或 DNS 设置,快速切换生产环境和备用环境

同时,在 IT 运维层面加强监控,也可以减少常见的内存溢出,磁盘满,网络失效,供电失败等操作或管理失误,提高硬件的可用性。

图 11.基于主备机模式的高可用架构

备份恢复

由于带库只能连接到 Power7 硬件,且挂载外部存储,可靠性较高。因此在 Power VM AIX 安装 DB2 数据库,同时对其整个操作系统进行备份,其中:

  • DB2 数据库所在的操作系统备份到带库:每月一次,2 盘磁带交替使用,保留 2 个月,用于操作系统的整体恢复
  • 由于带库备份操作系统只能识别 rootvg,鉴于 DB2 生产环境数据与应用分离的设置,数据所在的 datavg 需要进行额外的写入带库操作:每月一次,2 盘磁带交替使用,保留 2 个月,用于 DB2 数据库所在操作系统 datavg 中文件系统的恢复

注意:因为带库备份读写速度很慢,不保证文件系统中所有目录和文件的时间一致,系统备份 datavg 只作为恢复文件系统之用,具体数据恢复还要进行 DB2 Restore 的命令操作。

数据备份指对应用配置、数据文件的备份,每天 1 次备份到"数据备份专用存储",保存最近 7 天的备份数据,用于 WAS 和 IHS 的配置恢复,和 DB2 的数据恢复(如图 12),其中:

  • DB2 数据库导出 DB2 数据文件,用于 DB2 数据恢复
  • CLM/WAS 应用服务器和 IHS 反向代理服务器备份重要的配置文件和数据文件,用于快速恢复应用
  • 为了保证备份数据的可用和熟练恢复数据,定期实施对生产环境的恢复演练。
图 12.备份方式和频率

经验和教训

对于生产环境的规划和部署,同样需要适应需求的变化,基于拓扑原型的迭代和自动化部署手段,通过环境的演进来确认生产环境是否满足企业级研发管理平台阶段性需求。

参考资料

学习

获得产品和技术

讨论

  • 加入Jazz.net Community,与 Jazz 研发团队直接交流
  • 加入developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=1049311
ArticleTitle=助力 Rational Team Concert 落地,第 1 部分: 企业级研发管理平台的规划
publish-date=09052017