开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：研发模式的3个实践案例（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1286
研发模式的3个实践案例（二）
内容介绍：
一、案例一：P2P 直播 CDN 产品
二、案例二：基础网络产品
三、案例三：金融安全产品
四、总结
五、实践建议
六、回顾
四、总结
通过这几个例子可以发现，所有都是根据团队、本身的产品特征来确定分支模式的，这些分支模式里也尽可能减少分支，降低分支的维护成本，每多一个分支，维护的成本就会高很多，所有在选择分支的过程中，需要合理的考虑。在集成过程中，集成结束之后，发现集成分支有问题，需要摘出相应的代码，很多分支合在一起，可以使用临时的集成分支来解决。集成分支失败后，临时分出一个集成分支，把废弃分支摘除，其他的合进去就可以解决这个问题。阿里云的云霄就可以解决这个问题。分支可以很灵活的使用的，但灵活的使用会给程序员带来理解和维护的成本，所以分支越简单越好，另外尽量减少程序员关注分支的样子，让程序员只关注开发的分支上。
五、实践建议
1、单主干：一个代码仓库应该保证有且仅有一个主干分支。Getsflow 中 Develop和 Master 是很让人迷惑的。团队采用双主干或多主干的情况，一般最终拆成多个应用；
2、最少长期分支：在避免冲突的前提下，尽量减少长期分支的数量，太多的长期分支会导致代码基线的 tag 越来越大；
3、Promotion:代码的提交应该是逐级合并，如feature（开发）->develop->master,避免 feature->develop和feature->master 同时存在；
4、发布不可变：发布的版本应该是不可变且可回溯的，可以追溯找到源头；
5、自动化事件触发：分支的持续集成过程应该是自动化的，且通过代码提交事件或制品变更事件自动触发；
六、回顾
1、团队研发本质上是一个异步的、延迟协作的过程，随着产品复杂度和团队复杂度的增加，协作成本快速上升。协作成本会带来一个很大的冲突和等待的问题。
2、研发模式的本质是为高效交付需求，研发团队围绕代码库的一系列行为约束。围绕代码库的过程中，尽可能避免冲突和减少等待。
通过分支进行隔离，避免冲突；通过小批量频繁提交，保持信息的同步来减少等待。
3、控制分支需要考虑最大化生产力及最小化风险，分支尽可能简单，减少分支的维护和管理成本。同时，分支可以用来做一些隔离，频繁的提交和分支之间信息的同步可以减少彼此的等待。
4、分支的选择需要综合团队规模、协作成熟度、产品交付形态几个要素。上面举了3个不同的例子来证明这一观点。分支的模式和持续发布和集成的策略是息息相关的，从简单组合的角度来说，主干开发主干发布，分支开发主干发布，分支开发分支发布，主干开发分支发布，持续发布的话，采用持续发布的方式；需要版本制，采用 release 发布；如果需要做隔离，采用分支开发的方式。
分支模式不是很发杂，相应的概念需要在平常的产品实践中慢慢积累、理解。在实践中，随着团队的变化会做出相应的调整，并不是一成不变的。
课后作业
1．按照课程中示例分支模式的要求，配置对应的流水线和分支保护策略（包含代码安全监测和流水线卡点)
2.选择一个应用（如 alpd-bot-query)，添加一段代码（可以实现 README 中的一个 TODO），在 feature 分支上提交
3.创建一个 feature 分支到目标分支( develop)的合并请求，查看其检查结果4．通过该合并请求
5.创建一个 develop 分支到 master 分支的合并请求，重复步骤3、4
6．创建 Tag
7.查看 Tag 触发的流水线运行结果，保证应用能顺利发布上线
8.(可选）完成一个依赖两个应用的需求（如 alpd-bot-query 和 alpd-bot-ssh )，思考一下:跨应用的需求对我们的应用本身有哪些要求?对工具有哪些要求?
基于示例做一些分支模式的设计，可以选择一个或多个示例配置一个流水线和分支保护策略。
可以选择一个应用，实现 README 中的一个 TODO 并提交，走下来整个流程。
如果有一个依赖两个应用的需求，这时应该怎么做，对应用有什么要求，对工具应该怎么做，也就是一个需求涉及到两个应用，这时该怎么办。在此基础上，还可以想一下，如果一个产品涉及到很多很多应用，而且是版本级的方式，像前边提到的私有化的方式，又该怎样设计分支模式。
希望学习完工程实践的相关课程可以成为 develop 的 master。工程实践更多的涉及到一个团队、组织、公司的，希望能在公司里对相应的工程实践做相应的升级。
