开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：如何设计或选择合适的研发模式】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13514
如何设计或选择合适的研发方式
内容介绍：
一、 常用研发模式的选择
二、 持续发布模式
三、 分支模式示例
四、 落地应用实例
一、常用研发模式的选择
通过这一个问题来研究，已经知道了有哪一些常见的分支，并且它的一些优劣，而且设计分支的原则，选择分支的原则。有一个问题，就是怎么设计选择一个适合我们自己的研发模式呢？假设现在遇到自己的一个工作。产品的交付情况。怎么去做选择呢？
简单的一个参考，需要通过产品形态和它的发布方式，还有团队规模和协作成熟度来做选择相应的一个分支模式。比如团队规模很小，协作成熟度很高，那直接用竹竿来把现金足够类似这种服务端的web服务端开发方式，其实可以持续部署，所以这时发布的方式就可以通过github-flow来去做了，或者PBD，因为发布并不需要做相应一些隔离。所以这时团队规模适中，为什么失踪呢？就是有规模，有一定的规模，这时需要开发的时候，可能需要做下一些隔离，然后另外一个协助。比如一般的话就做了。
而另外一个有一些具有一定的发布窗口，然后是按版本的方式来去发布的，建议有相应的 release 之类去做这样的工作。通过这样的一个选择的策略，给出来的比如什么样的类型的产品，什么样团队规模，成熟度，需要用什么样的一个分支方式，当然这只是通过主流的这些分支方式来去给大家一些推荐，但实际过程当中应该尽可能地根据比较实际的产品。来去制定合适的一个控制规则，比如举一个例子。
这里是一个团队的协作方式，方式里是需求价值流，就是开发的时候，是一个需求接着一个需求的，做完了一个需求，再做另外一个需求。从需求的角度来说，交付是持续交付的方式，主要针对一个需求，会对应代码的变更流，就是针对需求，需要做相应的一些代码的一个变更。这过程其实是一种持续发布的方式.
二、持续发布模式
给出的政治方式是什么样子的呢？基本上是一个github- flow，就是在做特性开发的时候，只要做相应的一些特性之间的隔离，但是发布其实可以迟做到持续发布持续部署，所以就可以直接到master上就好。因为永远是在master上去发布的。而且不会有同时有两个发不存在，所以分支模式和本身发布流水线之间是由强相关的，因为发布流水线会给予你不同的分支来去做相应的一些事情，比如特性，分支已经发生变化了，需要去做什么相应的一些处罚，比如只针对特性分支，然后去做相应的一些集成和验证，之后才可以合到 master 上去做集成，做完了集成之后，做相应的 sight，所以发现分析模式和发布流水线之间是强相关的，这次持续发布方式，另外就是常见到的入手作为一个客户端的这种，IOS 或者 android，因为不可能持续发布，所以这时发现和上面的分支方式唯一多了一个 release 分支，跟这些用来给做版本。这时就增加了一个 release分支，从整体上来看，整个分支模式相对，所以当要去选择 flow，一定要用 github- flow，这时建议不需要用，只要用简单的能够满足你条件就好了，针对那些协作特别复杂的话，可以去选择，其实从现在的实际情况下，很少会遇到有需要 github -flow 这样的一个场景。
所以简单的了解了一下，发现其实分支模式或者研发模式，是为了减少代码协作当中的冲突，然后减少等待去创造。代码之间的协作的冲突有两种，一种是开发过程当中的冲突。隔离另外一个是发布过程当中，所以要么就是开发的时候多分支，然后发布主干发布，分支开发，主干发布，要不就是分支开发，分支发布，要不就是主干开发，分支发布，其实简单的一个就是一个二乘二的一个组合，所以简单了解了之后，可以看一下，遇到的产品分支方式是怎么样的？
三、分支模式示例
看例子其实初看上去跟它发了的是一模一样的。但是仔细看，会发现少了很多的东西，可以猜一猜，少了什么分支，看一下能不能看出来，有什么东西没有了，有什么变化。
其实相对 github 来讲，其实有两个变化，首先没有 release 分支。就发布是以主干上tag的形式去发布。第二个获得 fix，不适合回主干或者直接在 APP 上打 tag 的方式发布，这样就少了一个release的分支，或者master之间的一个同步。
所以，整个分支模式，就会形成一个特点，就是有四种分支，Feature分支，Develop 分支，Master 分支或者 hotfix 分支。develop和master是长期分支。
Master 和 hotfix 分支是短期的，然后开始开发布的时候，会拉一个小分支，最后和进去之后消亡掉，接下来，如果是是热修复，会拉一个X的值。分支永远从tank上空间来拉取，之后创建tag不能消亡，所以会发现就是真正的主干分支和真正长期分支就两个，大部分的情况下整个流程的比github-flow还是简化了很多。
四、落地应用实例
第一步，会先设置分支规则。
知道在模式里，Develop和master是属于两个长期。是不能直接提交的。Master应该从第二部分之和过来，第二个应该从评选分之合过来，所以这地方建了两条分支保护规则，逐一来看一下:
首先，有推送规则。比如 master，可以限制是必须是合并。允许合并可以开启开发者，或者只允许管理员，比如 master，比较严格，只能管理员合并，并且必须要经过代码评审和敏感信息检测确定。develop 的规则跟 master 类似，但是可以放宽一些，所以大概是如图的样子。
有了两条规则之后，两个分支就被保护起来了，不可能直接去push进去，只有经过特定的权限和流程才能把代码合进去。要去做流水线的配置，知道其实分三种逻辑，然后第四种流水线，一种是在开发阶段的流水线，是在剑锋之上的一种，还有一种是在发布阶段，是在master分支上。最后就是获得X，这里不打算去feature的流程，看一下正常的开发集成发布都是什么样子。首先看开发流水线。开发流水线它的特点是代码提交触发的，并且触发分支是feature分支。
所以这里配置了 feature-.*的正则表达式之后，任何像feature分支的提交就会触发流水线。回到了 develop。流水线是什么样子呢？作为一个集成水性来讲，跟刚刚的开发流水线很像。这里的出发分是 develop。同时这里的测试阶段，会比开发阶段多一些。可能会做安全扫描，可能还有功能测试，还有测试环境的部署等。这里为了节约时间，只配置了简单的几个测试任务。
假设集成也过了，接下来就是发布，所以发布流水线是 Master 触发的，就当代码从电话本合到 master 之后，同样是代码提交出发，出发的分支是master。会做什么事情呢？按照研发模式的规范，在代码合到 master 的时候，会需要打卡，表明在做发布了，并且把不固定下来，所以第一步会创建一个 tag。简单用别的 number作为TOD 的标签，当有了标签之后，需要跟镜像做一个绑定关联，在镜像构建的步骤里。用别的 number 作为镜像的表现。
这样发布的镜像的版本就是标签的名字就对应起来了。现在来来实际的去做一下，看看会发生什么。
创建一个分支。feature 应该是从 master上面的好确定之后。知道有一个代码是有一个 key 在里面的。是有安全隐患的，所以把 default API key 删掉。
就不返回去了，然后把 what 删掉：
之后，点击保存更新。
这时，相当于像feature分支进行一次。首先看流水线。发现开发流水线被触发了。然后开始进行代码扫描和单元测试。
在运行的中间，继续假设问题修复，现在需要去做继承，所以会创建一个合并请求。
然后可以指定一个评审人，这里就有自己。确定发现在中间它会自动的去跑流水线和敏感信息扫描，可以看到学习的结果是什么，敏感信息扫描的结果是什么，如果都通过了，觉得没问题早点通过。
如果都通过了，就可以把它合并了就点合并，点合并的时候分支的代码，就合到了分支合并里面，有好几种方式，默认的会创建一个模拟节点：
更倾向于最后一个，fast forward only的方式，就是如果要合到第二分支，意味着当前的需求分支要包含分支上所有信息。相当于和获利之后和获利之前的代码是一样的。
点击认为与方志敏不需要了，是个短分支，把它删掉，赶紧提交这时通知进来的一个commit，应该可以看到在流水线被触发起来了。
在他执行的中间，继续创建一个合并请求，希望把刚刚修复发布的。创建一个合并请求选择。评审人关联内容，其实是可以需求以及缺陷做关联，这样的话当修复一个缺陷的时候，其实可以在缺陷那边及时的更新了，甚至于状态的绑定。这不是今天的重点，所以就不赘述，点确定。
和之前是一样的。由于是同一个空间，看到会绑定到所有的流水线的结果也就是用 fast for only 的那种方式的一个优点，因为旁边的信息是一样的，也通过了，同样采用这种方式，这里因为对方是保护分支，不可能删掉，所以直接点提交就可以了。
刷新一下流水线。可以看到发布流水线也被触发起来了，第一个事情，就会创建流水线等到整个创建完，镜像构建发布就完成了。
所以有另外一个需求在开发，显然可以走自己的开发的一个分支，走自己的开发流水线，走自己的基层，走自己的发布。就通过流水线和防治保护这两个手段，加上一些安全卡口和测试策略，把之前提到的研发模式，做了一个营销商的一个落地。
