序篇：移动端研发效能的思考

为什么写移动端研发效能专栏

• 接触devops已有3年之久，且在腾讯跟快手两家公司均为devops的接口人，在实操方面有了一些感悟，希望有个地方可以记录下自己的相关经验

• 现网上关于devops的相关文章，均希望通过一套devops体系，满足所有业务方向。但是不同的平台开发，需要搭建的工具链是不同的。不同方向的读者在看到某些观点时，可能会疑惑。因此将范围缩小到移动端方向。希望可以帮助这个方向的读者

• 成就他人的同时也是在成就自己。希望在编写文章时，能提高自己的写作水平（很少写博客，求轻喷）

移动端devops的目标

不同的迭代模型有不同的目标。常见的迭代模型有这么几类

固定发版节奏模型：每隔一周（or 双周 or 一月）发一次版本，有版本节奏。每个版本都像一列火车，事先计划好什么时间点发车，若feature迭代赶不上本次版本，则顺延到下个版本。例如业界的腾讯视频团队，快手团队。

动态发版节奏模型：没有固定发版本节奏，没有固定版本迭代周期。例如移动端的动态化方案（RN，插件化等）支持的feature开发

项目制节奏模型：采用项目制开发模式的团队。如某个新产品的首发版本。如业界的央视频团队

针对上面3种节奏模型，着重讲解下普适性最强的固定发版节奏模型的目标。

缩短发版周期，提升质量

任何技术上的改进最终的目标都是给业务进行赋能。固定发版节奏模型的目标较为明确，缩短发版周期

下图是互联网普适性的移动端需求迭代流程

当前互联网是红海时代，已双周发版为例子，一年总共发布24个版本，即一个产品根据实验数据做出决策调整只有24次机会。这是远远不够的。如果能把发版周期调整为单周发版，能做出的决策就有48次机会。

当然，缩短发版周期并不是一件简单的事情。如果是简单地砍需求，跳过迭代流程等手段来强行缩短发版周期，势必会带来质量问题。