持续交付：微贷分支策略

今年，我们中间件和项管团队合作，做了微效平台。大部分功能大家都比较好理解，但是分支策略，是在平台上看不到的，也是不太好理解的，特别是对于我们为什么这样做。为此，我想通过这篇小文章，讲清楚我们现在的分支策略。

在此，我想先说明下我们现有的环境。

一、 微贷的环境

针对同一个系统，他所用到的环境如下。

• 迭代环境：开发环境，一个系统可能会部署到不同的迭代环境，系统不太稳定。
• 稳定环境：长期运行的测试环境，仅有一套，代码比较贴近线上环境，较稳定。
• 预发环境：长期运行的线上环境的预置环境，仅有一套，代码与线上一致，并且用同一个数据库。
• Beta环境：线上环境的第一台机器作为Beta环境的机器，在发布时，会切流，外部流量不会经过改环境。

• 线上环境：即生产环境。

  
  
  image.png

二、 微贷目前的分支模型

如下图，我们大部分的分支策略或多或少都可以归到这个模型中。我们暂且称该模型为==简单分支模型==

image.png

这个分支模型与环境的关系如下：

• 迭代环境：部署dev分支
• 稳定环境：部署master或dev分支
• 预发环境：部署master
• Beta&线上环境：部署master

看到这个分支模型的时候，我开始思考几个问题。

1. 这种分支会产生什么问题？
2. 若要不产生问题，该如何操作？

简单分支模型会产生什么问题？

1. 从master拉出来的dev分支，不稳定

因为稳定环境测试需要合入master分支，所以master中的代码可能是未测试完全的代码，此时拉出来的dev分支，很可能存在严重bug，并且，开发也不知道什么时候再去master拉取代码合入dev才是没有bug的。

2. 稳定环境抢占问题

测试将dev1部署到稳定环境，那么当dev2要部署稳定环境时，dev1的测试是不知道的，而且也没法控制，稳定环境就被dev2占用了，而dev2的测试也不知道在他之前代码分支是谁部署的，他想占用多长时间，现在是否还需要使用。这就是抢占问题

3. 生产环境可能会部署未测试的代码

在3问题上扩展，同样的道理。当我某个dev合入master并测试完成需要发布时，我没法控制到发布上线前的这个时间段内，没有人会提交代码到master。如果有人在这个时间段内提交了新的代码到master，那么发布的代码就很有可能是有bug的。

4. master中的代码有不同的发布时间，导致部分项目延期

多个dev的项目合入master，但他们的发布时间不一样。dev1希望12-17发布，dev2希望12-20发布，如果dev1要根据dev2的时间发布，那dev1就延期了。

如何解决以上问题？

1. 引入流程控制

能解决2、3问题

2. 增加一个分支int，所有dev分支需要集成到int分支，并测试

能解决1问题

3. 增加rel分支，所有的发布从dev拉出rel分支发布

解决4问题

将上述三个方案合成就是我们现有的分支模型--微效分支模型，详细的在微效的分支模型中展开讲。

三、微效分支模型

我们先简单看下我们的分支模型，如下图。其中有四种分支类型：

• master：稳定的代码分支
• dev：开发分支，可以有多个，部署到迭代环境
• integration：集成分支，仅有一个，所有的dev都需要合入integration，部署到稳定环境

• release：发布分支，仅有一个，部署到预发&Beta&线上环境

  
  
  image.png

1. 流程控制

我们的流程控制是如何做的，而不保证上述的2、3问题的？

1. 开发从master拉取分支创建为dev-x分支
2. 开发完成，申请集成环境（稳定环境）（引入审批流程，解决抢占问题）
   1. 当前集成环境无人占用：直接申请成功，并且从master拉取最新代码创建int分支，dev-x合入int分支
   2. 当前集成环境被人占用：需要占用集成环境的人审批通过，或者等待释放。
   3. 审批通过后，dev-x合并最新master代码，并合入int分支
3. 集成环境测试通过后，从dev-x拉取rel分支，并发布，这时会有如下两次检查来解决（3问题）
   1. 检查dev-x中的代码是否包含master最新代码
   2. 检查int分支中是否包含dev-x的最新代码
      4.发布完成，将rel合并入master

在上述流程中，我们引入了集成环境的审批，来解决抢占问题（2问题）。

同时，我们在拉取rel的时候会比较dev与master的不同，int与dev的不同，来保证dev的代码是在int中被测试过的，并且是有master的最新代码，来保证3问题不发生。

2. 微效如何保证master代码的稳定性？

要讨论这个话题前，我们需要定义下，什么样的代码算是稳定的？

每个人的理解可能有差异，我姑且将发布上线后的代码就称为稳定的代码。

那么，我们来仔细观察上图的微效分支模型，会发现，合入master的途径只有一个----rel发布完成合入master。所以我们只要保证rel的代码是稳定的即可。而rel中的代码是在稳定环境测试通过，包含master最新代码的要发布上线，并且在发布成功后才合入master，这时我们认定这个代码就是稳定的。这样我就解决了master代码不稳定的问题（1问题）。

3. 各项目发布时间节点不一样怎么办？

如果没有我们的分支模型，大家可以想下怎么解决这个问题？

很简单，发dev分支的代码不就好了吗，免去合并发布的各种烦恼。

那么，我们剩下的就是要解决dev分支的稳定性问题。实际上，我们是引入rel来解决该问题，而rel对应的只会是一个dev分支。而在前面我们已经讲过如何保证rel的稳定性。

但这时又出现另个问题：相同时间段有两个项目同时发布的怎么办？

我们的解决方案就是rel分支只有一个，同个时间段内需要同时发布的项目，要排队。

这样就解决了发布时间节点的问题了（4问题）。

4. 发完之后有bug怎么办？

---

经过上述的流程和分支模型我们解决了简单分支模型会产生的问题。但是，这会不会产生新的问题呢？有想法可以留言哦。