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有好多个微服务，每个微服务在开发过程中，都是采用分支开发，主干发布的方式，具体的流程如下：

 

• Master分支要时刻保持可发布版本的状态；
• Develop和release分支是测试分支，对应不同的测试阶段；
• 每个特性都要单独拉feature分支开发，并合入Develop和release分支进行测试，测试通过后才能合入master分支；
• 在迭代的过程中，如果遇到现网问题，则在master分支拉取代码到hotfix分支，测试通过后再合入master分支发补丁；
• 代码review只需要在release和hotfix分支合并到master分支时进行就可以过拦截大多数代码缺陷

这样的分支管理方式，每个特性完成开发后，测试通过即可发布上线。一个需求完成之后无需等待统一版本，可以灵活发布。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