其他分享
首页 > 其他分享> > ProjectMan是这样炼成的

ProjectMan是这样炼成的

作者:互联网

引言

大家好,我是华为云DevCloud 管理与协同域的产品经理恒少

有句话叫做:“恒少出品,必定来自双手沾满泥的实践”

随着DevCloud的客户逐步了解敏捷/DevOps的理念,并实际基于DevCloud进行软件交付后,更多的客户提出新的问题:你们能不能分享你们每天都怎么开发的,你们的团队组织是怎样的?有哪些坑?有哪些雷?

为此本期的“双手沾满泥”的实践,特别邀请长期与恒少奋战的Service Leader亲自撰文“Projectman 是如何炼成的”

前言:

提到ProjectMan,可能很多人没听过,但是只要提到中文名称:项目管理服务,不少用户可能会听说。简单说,ProjectMan是DevCloud的一个服务,提供项目、成员、需求及缺陷管理等功能,是DevCloud使用最频繁、用户最多、UV/PV都比较高的服务。

而我就是这个服务的研发团队负责人。有一次,一个客户跟我反馈说,他们在研发的过程中,经常遇到各种各样的技术问题,而华为有三十年研发经验,能不能分享一些技术方面的文档,让他们能够参考和学习,提高自身的研发效率,避免走一些弯路。我认为确实很有道理,客户的研发效率提高了,既对客户有益,也符合华为的利益。于是我先抛砖引玉,先介绍一下我们服务,如果效果好,可能会有更多比我经验更丰富的专家出来分享技术干货,希望最后DevCloud不仅是提供研发效能的服务,也能形成一个华为与客户之间技术分享和交流的平台。

我们的故事

很多IT创业公司在最开始的时候,为了快速抢占市场,对产品研发的时间要求是非常短的。我们也一样,第一个版本要求在一个月内上线。为了快速开发,我们调研了很多已有的项目管理工具,最终选择了基于公司内部的一个已有的架构进行开发。后端使用SpringMVC+ MyBatis框架,MySQL数据库,前端页面则使用Angular框架开发。

像大多数系统一样,第一个版本上线以后,大量的需求蜂拥而至。随着不断叠加的功能,代码的复杂度变得越来越高,维护成本也越来越大。

去年年底,我们顶着巨大的压力,对系统进行重构。为了使代码解耦,功能模块之间可以独立升级,我们把后台一个微服务拆分成了四个微服务。同时我们更换成了功能更强大的Spring Cloud框架。

在系统重构的几个月里,我们并没有中断需求的交付,仍然以每周一个迭代,每个迭代几十个需求的节奏运作,一直到今年3月份才完成。重构之后,我们的代码结构得到了优化,不会互相影响,现网的问题比重构前减少了80%以上,而且不同功能模块之间升级互不影响,平均每天至少一个微服务在升级,大幅提高了需求交付效率。接下来我就介绍一下我们是如何运作的。

团队运作

1.我们的团队是全功能团队,独立负责ProjectMan端到端的交付和运维。总共有10名开发人员,包括4名前端和6名后端,因为总共有6个微服务,所以平均不到2个人负责一个微服务。而且,没有专门的测试和运维人员,所有测试和运维工作全部由开发人员承担,例如用例、环境部署等,可以说我们每个团队成员都是集开发、测试、运维能力于一身的全能型人才,每个角色在主要工作分布上略有不同,作为Service Leader的我会更多承担一些服务设计的工作,但是我写的代码,也一定是我自己测试,自己部署

2.研发流程模式上,我们采用scrum,固定每周一个迭代,每个迭代会发布多个版本。为了打磨我们的产品,我们所有的工作都使用DevCloud ProjectMan上来管理,用业界时髦的实践就是“吃狗粮”。产品经理会将需求按照Epic-Feature-Story的层级整理好,然后通过迭代会议制定迭代计划,大概的流程图如下:

 

 

3.分支模式。Projectman有好多个微服务,每个微服务在开发过程中,都是采用分支开发,主干发布的方式,具体的流程如下:

 

这样的分支管理方式,每个特性完成开发后,测试通过即可发布上线。一个需求完成之后无需等待统一版本,可以灵活发布。4月份,我们总共发布了40多个版本,平均每个工作日2个版本。

持续发布,持续监控

既然发布版本这么频繁,如果没有一个高效的发布工具,是万万办不到的。这个工具就是DevCloud上的流水线,及其调用的代码检查、编译构建、部署等任务。每个微服务会创建一条流水线,上面集成了代码检查、编译构建、部署、自动化测试等任务。而且一条流水线会将所有环境串联起来,研发环境测试通过之后,才能执行下个环境,最后是生产环境。虽然华为的研发流程比较复杂,发布到生产环境之前要在其他4个环境测试通过,但是由于这些都由流水线自动完成,所以总共只需要20-30分钟即可完成版本发布。

在现网,我们使用了很多华为云的其他资源,系统是部署在华为云的ECS上,总共几百台虚拟机实例,数据库使用RDS,文件存储使用SFS等等。得益于自动化运维平台,这些资源,我们开发人员自己可以维护。我们不仅可以在所有节点查看日志、下载文件,还能批量在虚拟机上执行脚本等等。不仅如此,为了能快速响应现网问题,我们采用监控平台对现网的报错进行监控。一旦报错,哪怕只是一个错误码,或者抛个异常,都会被监控平台捕捉到,并且会精确到哪行代码出了问题,然后给负责人发短信提醒。除了对异常的监控,我们对性能指标、资源使用情况等都有监控。

结束语

作为一个Service Leader,业务交付的效率,服务的质量,用户的增长和活跃,架构和技术能否持续健康,甚至控制服务运行所消耗的资源成本,如何削峰填谷,都是需要平衡考虑的。这里面包含了很多的思考和实践,我们会根据大家的反馈,陆续分享一些内容。

作者:SODA(DevCloud Service Leader),恒少

标签:服务,迭代,炼成,代码,ProjectMan,DevCloud,我们,这样,分支
来源: https://blog.51cto.com/u_15214399/2823312