华为项目CMO(CIE)的经历，对软件工程敏捷开发的实践

0、此文章的初衷

以前在项目组里开发的同时担任了大半年的CMO工作，年幼无知的我一开始觉得这工作是帮领导打杂，后面确实有很多收获。
此文分享自己的经验，希望获得更多交流提升。
读者如果是作为普通开发者可能看不到这么多细节。但是从CMO的角度，可以看到项目的全貌，看到怎么使用工具去提高代码质量、量化指标，希望你能有所收获。

在这里就不去涉及具体项目机密，以下涉及的工具皆为已公开在业界的。有时间继续完善。

想要一篇文章写完所有内容应该不太现实，以下来自于我的项目中的相关总结大纲，大概和我当时交接文档类似。目录可以从PC网页的右端浏览。
简单来说，大纲主要是下面：
2~7、9节是工具配置以提升代码质量
第8节是完整版本发布流程以配合周边项目
第10节是待改进的方面
第11节是海思的CI

1、什么是CI，什么是CIE？

1.1、CI

项目的持续集成（Continuous integration,简称CI）。
在我看来，CI是每个团队项目都需要进行的一项重要活动，如果团队里没有这一套方法学，那版本的管理、代码的冲突、甚至是回溯问题都会非常困难。

1.2、CIE/CMO

CIE或者CMO，即CI工程师或者叫配置管理员。基本工作是把需要部署的插件及时配置起来，确保所有相关机器都能使用，还有各种代码及相关文档的版本的发布和归档（在研版本和维护版本）。

1.3、要求

我个人觉得这个工作的要求主要是：

• 对linux shell命令熟悉
• 最好懂一些C的编译选项
• 懂软件工程（理解敏捷迭代，有对开发流程的全局理解）
• 了解web后端配置（Jenkins）

2、内源社区（Isource）的代码门禁系统

华为那段时间几乎全员切换到了git，开始内源社区，一开始很多人不习惯，感觉环节多，很鸡肋。
其实内源社区的用处很大，社区能互相学习，而且门禁系统也是让代码质量得到一个很大的提升，在后面的一些安全整改问题上，借助这些工具，让英国客户信得过我们的产品。
代码门禁系统就是你在上传代码时候，如果被这些门禁拦截住，那是不允许合入的，而且Committer也会检查，看板会有统计，假如你经常提交一些不符合规范的代码，那会给团队带来影响。
代码门禁工具很多，比如：开源代码检测FOSSID、Lint、代码冗余度、圈复杂度…

3、CI的机器类型

按ICP-CI系统（智力资源池，属于华为自研），分为四种类型的机器，分别是Master、POM、Proxy、Agent机器。
Jenkins的会简洁一些。
简单来说，机器资源充足，能让机器各司其职提高效率，实现功能有任务分配和主备切换等等。

4、RTOS

RTOS（实时操作系统）是我们依赖的环境。
项目组里VxWorks和Linux两种环境都会使用，注意区分。
不同产品版本和编译环境是不同的RTOS，后来部门统一拉齐了，才让环境变得简洁。
RTOS更新或部署的脚本是分几种类型的，注意按顺序安装（应该弄个通用的安装脚本，减少人为干预）。

5、ICP-CI（华为的旧CI系统）

5.1、权限申请和管理

对于临时支援或者外部门的人，做一些权限的区分，回收权限时候不能影响正常工作。

5.2、CI config文件之间的关系

5.3、映射RTOS

5.4、Simian配置

Simian是一种冗余代码检查工具。

5.5、Agent机器经常磁盘不足，解决方案

找有经验的同事，以及查看编译脚本，识别哪些是可以定期或者及时删除的文件。

5.6、Jmx用户和密码的查看方法

5.7、Fossid

开源代码扫描，属于业界工具。

5.7.1、如何查看Fossid结果

5.7.2、CI config

5.7.3、Fossid网站使用和继承

5.7.4、可能遇到的问题及解决方法

6、Jenkins（业界流行的CI系统）

6.1、Isource代码门禁

6.2、二进制一致性

总之最终效果是能保证两次不同环境不同时间编译的同一个版本的交付件二进制是一模一样的，可以保证溯源。解决这个问题的中间遇到过不少问题。
网上没有公开，先不细说，配置起来特别头疼的一块，花了不少时间。

6.3、Fossid

7、项目VPN

7.1、怎么分配地址给各个人员，防止冲突

8、版本发布流程说明

这是最重要且有点复杂的工作，因为流程目前还比较长。
要注意其中的顺序，不能越了某一步，那可能引起项目组与组的矛盾，那就凉凉。

8.1、10+个产品代码库的路径及介绍

涉及产品，不细说了，总之就是产品有多种应用在不同垂直细分领域，之前大家都不关心，以为产品就一个库，我给项目组列清楚了详细的表格及介绍，很多开发才搞明白。
我觉得最好开发还是了解一下自己的下游产品，不能只是简单的知道有一个大概什么的产品，如果了解了具体的应用场景，那便于我们写代码时候就举一反三，减少bug出现的概率了。

8.2、交付件归档在内网

除了代码编译出的交付件，也有不少版本的文档。

8.3、周边接口人

各个产品组（产品不同版本、不同依赖，是分了许多组的，而且人员会变动（比如产品大版本会分不同版本的责任人），他们之间有时候也会信息不通，所以务必知会到所有相关人）。
这里的方式也是列出一个很大的表格，把周边接口人的关系列清楚，注明日期，及时更新。

8.4、版本发布前的准备工作（待补充）

8.4.1、版本计划，从很早制定的IPD中，在具体到每个TR点和每个关键问题单，可以看到这一两周的版本需要做什么

8.4.2、确定版本发布时间：根据版本计划，与测试沟通

测试的人力和机器也有限，需要和开发对齐计划。
正式流程中，测试会及时对问题单进行一个测试策略澄清，以提高测试用例的命中率。

8.4.3、问题单系统（华为DTS系统和业界常用Jira）

自研的DTS更加定制化，符合产品线的IPD流程。
本文就简单介绍一下，具体资料网上有很多。

8.4.3.1、为什么需要问题单

简单说就是用来跟踪问题，以及回溯问题，方便上层人员看到项目概况。

8.4.3.2、按提单人分类

按提单人来看，一般有测试问题单（下游产品测试、自己项目组测试）。开发自提单（来自架构师发现的问题、上游的海思芯片、底层操作系统、硬件、自己项目组开发、CMO等等）

8.4.3.3、未定位的问题单

可能问题还在其它高层架构的组里，大家一起定位问题，如果是自己组的，就同步问题单到自己的组里，注明相关定位信息。为什么要同步（即复制一份）问题单到自己项目组，因为项目组的测试和上层产品项目组那边有不同的测试，自己项目组的单涉及到自己项目组的测试人员的KPI。

8.4.3.4、回溯的问题单

比如由于修改没举一反三，或者其他修改引入的问题…

8.4.3.5、修改代码

记得要举一反三想想有没有类似问题，合入项目组的git仓库，comment中注明问题单号。
comment有具体的规范，这里不扩展了。

8.5、自测试

8.5.1、编译机器

遇到个导致效率低的问题，就是项目老版本的编译环境没有人维护，用shell脚本的编译出问题，导致我们要找Windows机器使用bat编译。需要花时间去研究修改shell脚本。

8.5.2、冒烟以及相关自测试的环境准备

在项目组的自测试环境，以及在产品项目组的自测试环境进行自测。
如果环境紧缺，得提前去协调。建议是能把环境准备充足，避免大家互相抢环境。在环境有限的情况，如果自己协商不到资源那要及时求助，因为发版本的节奏一般是很紧张的，上下游可能都早早把时间给卡死了。

8.6、各文件归档

8.7、项目组版本发布通知-邮件规范

当上下游版本变更时候即使更新，在邮件里写清楚对应的版本。邮件是很重要的，大家都懂的。

8.8、最后把CMO归档的问题单走给测试组

跟踪测试进度…

8.9、走发布电子流

8.10、测试完成后合入产品库

提前了解产品项目组的项目计划，如果当天回封版（封库），要再知会领导，协调相关人员。

8.11、版本转测试电子流

8.12、维护版本

因为维护版本是已经在现网（真实环境）商用的，对于每个改动都要谨慎已经做好记录跟踪。
维护版本的问题跟踪、总结、典型案例、版本计划、代码归档路径…

9、项目健康度面板

新推出的，增加了各种指标，全公司软件项目组都能互相查看健康度数据，巩固代码健壮性。

10、待优化改进

为了编译效率，对编译选项以及可能的改进点，在项目中灵活使用。
单元自测试的自动化待加强，可以减少重复人力。
对于文档类的操作，可以学一下python模拟键鼠操作，减掉一些重复劳动。

11、海思红区CI

11.1、配置方面

海思的办公基本是直接组里多个人同时在使用相同的云计算资源，对于大型程序比较吃内存的情况，要合理安排机器和时间段。
机器申请（找组内有经验的人和部门的资源管理人，一起协商需要的机器输了和具体配置，根据项目进度增删）。
红区的多种权限申请和管理，对于临时支援或者外部门的人，做一些权限的区分，回收权限时候不能影响正常工作。
使用top命令以及磁盘管理工具查看人员使用情况以及一些无效的进程。

11.2、项目迭代的特点

海思的测试的工位是紧挨架构师和开发的，沟通起来很方便，可以直接当面交流，因为芯片涉及硬件工艺，迭代周期很长，所以只有一些节点才会发布正式版本。

文章更新记录

• 2020年3月20日 补充了海思红区CI、邮件规范、RTOS、Fossid、编译机器的内容，以及修改了一些文字错误。
• 2020年4月12日 用markdown在最前面增加了目录。