首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >DevOps之软件产品管理最佳实践

DevOps之软件产品管理最佳实践

作者头像
yuanyi928
发布2018-04-02 15:56:33
8350
发布2018-04-02 15:56:33
举报
文章被收录于专栏:EAWorldEAWorld

大家好,我是王召,现在负责新一代数字化企业云平台 “The Platform” 的SPM、MKT领域系统。很荣幸这次有机会和大家分享“DevOps领域系统之SPM” 。

也许有好多朋友是新进来的,不知道我们新一代产品做什么,所以在开讲之前我会发一张普元新一代数字化企业云平台规划图。

我们抽象SPM这个概念经历过两个阶段,分别为:M1阶段和M2阶段。

M1阶段:我们抽象出SPM(软件产品管理)概念,因为在实际情况下变更是经常发生的(主要是纵向的服务或者容器的伸缩、横向代码以及配置的变化),所以其主要负责产品相关概念基准定义与依赖管理以及相关配置的管理;其包括产品类型、产品管理、组件管理、组件管理、产品与组件配置项管理、依赖产品管理、部署架构等,能够很好定义各个产品之间的关系,便于产品实现自动化编译打包以及自动化部署,查看服务调用关系。

M2阶段:在M1阶段,我们把配置分成配置项与配置值,由于在实际情况我们一般会存在四套环境(开发,测试,预发,生产),配置值经常发生变化以及以后会做配置发布、配置更新自动化等(类似百度Disconf),所以我把SPM领域系统拆分出来了SCM(软件配置管理,下期我们做详细介绍),SPM只负责产品相关概念基准定义与依赖管理,不做配置的管理。同时,这样做的好处是减少打包的时间与储存空间。

在介绍SPM概念模型之前,我会把与SPM相关的领域系统做一个简单的说明(更详细的介绍见后面的微课堂),内容如下:

VCS:版本管理领域系统,目前已经集成gitlab

PM:Project Mgmt简称,项目管理

SCM:Software Configuration Mgmt简称,软件配置管理

SRM:Software Release Mgmt简称,软件发布管理

MKT:Market简称,软件市场管理

从上图,我们可以看出SPM主要概念模型有产品,产品版本、组件。其概念模型也会与VCS、PM、SCM、MKT、SRM中的概念模型有所关联,具体表现为:

(1)一个产品对应一个Git库,产品不同的版本对应Git库不同的分支;

(2)一个产品版本对应PM的一个项目,项目包括功能与缺陷

(3)在SPM内部,一个产品可以有多个版本,每一个产品版本包含多个组件

(4)一个组件对应SCM中多个配置项

(5)一个市场类型下有多个产品,一个产品版本根据产品的规格不同可以发布多个市场标准产品;

同时,组件可以依赖多个市场中的标准产品

(6)组件可以选择SRM中的多种部署模型,便于进行自动化部署

SPM与DevOps其它领域系统中的SRM、VCS、MKT、PM、SCM都有一定的依赖和交互。SRM做部署时,需要知道产品与组件、组件与依赖产品的关系,由SPM提供这种能力;VCS根据产品的code创建git库,根据code加version创建分支;SPM的产品可以发布到市场,供第三方或者自己使用;SPM的一个产品版本对应一个PM的项目,该项目对该产品版本进行管理(功能与缺陷);SPM提供组件信息,便于SCM对该组件的配置项进行操作。同时,所有领域系统提供的API会Portal进行组装与结合,对客户端提供能力。

上面两幅图都是描述产品创建的过程,具体步骤如下:

(1)创建项目与团队,同时从MKT选择产品的类型,创建产品以及产品版本

(2)选择组件支持的部署模式,创建上面产品包含的组件,同时创建该组件依赖的产品(其中依赖 产品来自MKT的标准产品);

(3)克隆依赖产品的配置项给相应组件,同时定义组件定义配置项;

(4)创建此产品的Git库,以及步骤(1)中的团队成员附相应的权限;

(5)修改SPM的产品的状态(有设计进入开发阶段),上面产品的Git地址检出代码进行开发;同 时,修改MKT的标准产品的状态为未发布(只有标准产品状态变成已发布状态,才能被第三方使用)。

以上步骤,(1)同步通信过程,其他均为异步通信过程

上图为概念模型得出的数据模型。

上图描述的是两个产品交互的过程,API为产品提供的能力SPI为产品对外需要依赖的能力,增加能力适配Adapter来适配不同提供方的API。比如,VCS是我们平台提供的能力(API),同时VCS会定义自己依赖的SPI,Adapter对Git,SVN,CVS等版本管理工具的API进行适配。

那么,我们会面临一个问题,微服务架构会把应用按照业务粒度拆分不同的微服务,不同的微服务会相互交叉,形成网状结,如何进行有效管理呢?在实际工作中,我们不仅要知道产品内部组件之间的关系,还要知道每个产品之间关系,甚至需要提供各个系统API接口的变动会影响到那些被调用领域系统的SPI接口,或者SPI接口调用了哪些API接口?我们使用元数据进行分析管理,其价值体现为:一、提供产品边界以及交互模型;二、规范微服务开发和使用

上图为SPM的API变更会影响范围局部分析图。

上图为SPI改动影响范围分析图。

上面两幅图(第一个为打车应用微服务产品关系图,第二个为我们新一代数字化企业云平台部分微服务产品关系图)所呈现的是实际使用服务时的服务整合情景,不同微服务产品在不同的业务场景下被依赖和引用的程度不同,每个微服务产品提供的能力数据由业务复杂程度决定。成千上万个微服务产品在运营环境下高效地运转,这就要求产品必须有标准规范。标准规范分为两个方面,一方面是产品的数据标准,另一方面是产品的服务标准。而这两种标准都需要元数据定义。

具体体现到SPM领域系统包括以下两点:(1)产品或者服务进入软件市场的标准;(2)定义产品或者服务之间的依赖和引用关系,从任何一个产品可以分析出整个调用关系(上面画的API影响范围以及产品开发和使用关系图),便于对于产品进行全生命周期管理。

关于作者:

王召

现任普元信息资深开发工程师,为普元新一代数字化企业云平台开发团队一员,负责新一代SPM(软件产品管理)与MKT(软件市场)领域系统的开发。曾在百度西北营销自主研发中心、格林谈谈科技等互联网公司从事开发经理工作,曾主导开发过多款电商和社交项目,并获得风险基金的投资。平时喜欢旅游,骑行,爬山等活动。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-08-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 EAWorld 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
CODING DevOps
CODING DevOps 一站式研发管理平台,包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务,涵盖软件开发从构想到交付的一切所需,使研发团队在云端高效协同,实践敏捷开发与 DevOps,提升软件交付质量与速度。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档