从零开始部署企业智能硬件CI环境DevOps篇（三）

开始之前

在笔者有限的职业生涯中，有长达4/5的时间是围绕Android端上软件研发工作展开的。从需求评审到功能开发，从代码提交到解决线上测试问题，如此往复。
这条道路虽然艰难但并不复杂，只要严格按照工程排期做好自我能力评估，总是能在力有未逮前处理完所有问题。

然而自从加入这个团队后，这个循环就被打破了。原因也很简单，我的视角从“执行者”转成了“推动者“。研发的工程交付只是整体项目交付的一个环节，在此之上还有产物的交付、迭代的交付以及项目的交付。而这些内容环环相扣，一个环节的结束往往不再由个体来决定，最终的交付成败是所有人共同努力的结果。

交付困境与DevOps

如果说得更加具体一些，在我所了解的大部分场景里，项目出现质量问题或者团队长期加班的原因都与项目交付问题息息相关。这当中有主观的问题，比如研发delay、测试delay导致，也有客观的原因，比如突然增加的重要需求。然而站在交付质量把控层面，有些问题还是可以消弭于前期的。

就像敏捷宣言、Scrum、精益思想一样，DevOps也是一种自实际生产行为转化为顶层行为理论的概念。我并非DevOps理论的鼓吹者，但在真实场景中，DevOps于精益思想和敏捷开发方案一样，都在切实改善相关问题。

业务推动的变更

DevOps的主旨之一是打破“研发运维墙”，在我们的团队业务场景中，研发运维的对立关系并不如在线产品那么明显，反而是研发与质量的关系更为纠结。一次完整的迭代交付是从PM需求开始，从QA回归验收结束，期间交付的流程中一些常见的问题最终解决策略如下。

项目编译交付改善

由于项目的特殊性，我们的交付产物中既包括硬件也包括软件功能，而软件功能不但包括通常意义的Apps/SDK，也包括Rom。虽然在整体的提测方案中，质量团队只接受整体Rom二进制文件作为最终提测产物，但这并不是最完善的方案，而后续低效的迭代情形也逐渐暴露出来。

App的编译产物直接集成在Rom中，以Rom的方式提交提测。这种方式的不利之处在于：

1. Rom的编译时间比较长，难以做到快速