开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：研发模式的3个实践案例（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1286
研发模式的3个实践案例（一）
内容介绍：
一、案例一：P2P 直播 CDN 产品
二、案例二：基础网络产品
三、案例三：金融安全产品
四、总结
五、实践建议
六、回顾
一、案例一：P2P 直播 CDN 产品
分子模式是与产品的形态，团队相关的。
为直播平台提供 P2P CDN 视频加速服务，架构图如下，可以分为两部分，客户端和服务端。客户端是多端的，手机、路由器，机顶盒，每一种端的发布形态是不一样的。终端与客户端，服务端之间有两条通信链路，一条是视频数据的链路，一条是控制数据的链路。简单来说，服务端包含三部分，控制面，用户面，数据、运营、监控等服务。每一块都包含有很多具体的应用，比如用户面，控制面每个都有十几个甚至二十个应用，所以整个架构就是图中描绘的样子。
团队是10人左右的扁平团队，没有专职的测试和运维，可以认为10个人都在做产品；都在一起，所以团队内协作紧密；工程能力中上，有较完善的单元测试和功能自动化测的保证，基本上可以做到比较快的测试反馈；技术背景是以 C/C++、golang 为主的，业务的特点一般来说对于内存、性能比较关注。有两种应用，服务端应用和客户端应用。服务端中，C/C++、golang 是通过源码级依赖做构建；运行时除配置中心外基本没有其他的依赖了；总共应用数大约30个左右；一次发布一个应用，每个应用是可以独立发布的，所以不存在发布的依赖性，编排问题；部分服务由于网络转发性能，必须采用物理机部署，也就是说没法用 k8s 或容器这样的方式。
客户端是多端的，但只有一个代码库，所以一份代码，多端构建；同样是没有运行依赖的；有的可以热更新，但有的需要通过应用市场来发布，只能保持很多个版本；发布频率不太相同，一般最多一周一次，导致会有很多长期版本的存在。
首先服务端应用研发模式，服务端看上去比 tbd 还要简单的模式，因为人很少，服务拆分得足够小，通常一个应用同时只有1~2个人在修改，这种情况下就没有必要做履历的分支，在一个主干开发，一个服务一个库，平均一个人3、4个应用，所以这个服务是很小的，这样的情况下有一些纪律，要保证多端，要保证客户端多版本，所以代码提交需要保证向前兼容；同时，所有的修改都会直接 push 到 master分支上，不存在合并的问题；每次 push 之后都会触发对应的自动测试，如果测试失败，提交者需要在一小时内修复；在master 上创建 Tag，即会视为一次发布，Tag 会触发一条流水线，流水线做一次发布；出现问题在最新代码上修复，永远发布最新的版本，这就是服务端的流水线。如果团队出现类似状况，建议使用 master，在做好纪律的前提情况下，可以做到很高效的发布。从反馈的角度来看它是特别快的，一旦出现问题，需要立刻响应，如果有更多的分支，修改时间可能会推迟，也就是延迟反馈，延迟反馈会带来很多的问题。
客户端形式有些不同，基本上是 tbd 的方法，平常还是由主干来开发，代码在主干上做集成，但是客户端有两个特点，发布和升级比较困难，所以需要做足够多的发布前的验证，这种情况下，需要专门的 release 分支进行保护；同时考虑 bug fix 的问题，因为会同时存在多个版本，所以在 release 分支上进行 bug fix；另外release 分支要保证活跃数可能的少，一般只关注最新的活跃 release 分支。在这种情况下，tbd 是 非常合适的一种方式。针对发布来说会做相应的分析隔离，发布分析相对来说建立这个版本有一定时间的维护，需要相对长期的 release 分支，维护到下一个大版本发布，但一般来说至少维护两到三个版本。从产品的真实经验来看，长期存在的版本数可能超过10个，因为没有办法进行任意的升级，发布版本的管理和维护是一个很大的开销，所以尽量让它升级到最新的 release 版本，但做不到的话，就只能fix。
二、案例二：基础网络产品
案例二是比较底层的产品，也就是基础网络产品。在虚拟基层面上层做了一个虚拟化网络的产品，外部做底层产品的一些公司可能会遇到类似这样的产品。团队是50人左右，每个团队大概是10人，大概有5个团队；团队间协作需求高，产品通常需要—起联调、一起集成和发布；整个团队工程能力中等，有单元测试，但没有其他测试的保护，所以主要靠环境测试；开发语言以 C/C++为主；部署到物理机或者虚拟机上。
应用是一份代码，多端构建，要应对多种硬件和操作系统的区别；底层依赖hypervisor，也就是虚拟层以及硬件内层；升级时需要停机，网络的问题不是很容易做到热分析；一次发布一个应用，但有发布顺序要求，发布多个应用时，应用间的发布是有编排顺序的；发布周期是很长的，整个更新周期需要几个月的时间，所以通常几个月发布一次，而且可能会存在两个都在进行的发布，一个百分之八十，一个百分之十。
这种产品怎么设计它的一般模式，与上一个不同，与客户端的发布有些类似，但他的履历分支会更长，而且需要固定的版本，有明确的tag，要合回 master，master分支为发布分支，不允许直接提交，永远指向上一个已发布的正式版本；开发是用release 做，release 分支为开发分支，从 master 分支创建，开发完毕，通过评审和测试后合并回 master。有些类似于项目制，即一个 release 相当于一个项目，从master 上拉出来之后，发布的工作都在 release 分支上，release 就相当于项目的一个版本，在这个基础上做，做完之后，release 分支就进入维护阶段，就可能对另一个项目如 release2.0做一系列开发工作，到一定程度之后，release2.0又会进入到维护阶段。区别就是 tag 打在了 r elease 分支上或者 master；master 是发布的时候，master 在这里永远做基线管理的。
三、案例三：金融安全产品
与其他产品不同的特点是同时提供 SaaS 和私有化交付形态的金融安全服务，一份代码提供 SaaS 和私有化两种交付形态。整个应用架构相对简单，有一些后台服务，客户应用接 API 服务，控制台用来做配置，后台服务中 API 会调用很多其他的服务，设备指纹，指标计算，数据服务等，很多人工智能、大数据的产品都是类似的架构。整个团队150人左右，但前端、算法、后端、测试都有专门的职能团队，没有专职的运维；团队间通常需要协作才能完成一个需求；工程能力一般，无单元测试和自动化功能测试，基本上靠后期人工测试来保证质量；Java 技术栈，docker&k8s 部署方式。应用特点是二方包依赖较多，snapshot 和 release 版本都有，这种依赖是不确定的；运行时应用间有较强依赖，API 可能会依赖设备指纹，API 依赖指标计算，类似这样的依赖有很多；整个应用数20个左右，100多个人，只有20个应用；应用相对较大，应用是很多人协作完成的；—次发布一组应用，不是一个应用；SaaS 版本落后私有化版本较多。
master 分支为发布分支，不允许直接提交，永远指向最新可发布版本；release 分支为临时集成分支，从 master 分支创建，合并入 master 分支后删除；作为私有化可能一个月发布一个版本，这一个月就会分出一个 release，release 分支用来做一个月的集成，与上面说到的项目制有些类似；集成结束，会合回 master 做发布；feature 分支为特性开发临时分支，从 master 分支创建，合并入 release 分支后删除；hotfix分支为快速修复临时分支，从 tag 创建，修复后打tag后删除分支；发布都通过创建tag 触发，tag 即为版本号。这里的 release 分支更多的相当于迭代的分支，整个测试是比较长的周期，同时也要维护多个版本，所以就会有多个 B 型的 release分支存在。
