绑定Git Pull Request和部署目标环境

访问公众号菜单->精华文章->Git浏览《Git企业开发者教程》基础篇

在 《Git企业开发者教程》基础篇的最后，我着重介绍了使用 Pull Request 来加强团队对代码质量的关注，同时也提到了使用 Pull Request 配合 CI/CD 将能够实现更好的持续交付场景。其实，对于持续交付过程的改进一直都是我给客户实施DevOps以及我自己的开发团队的日常工作重点。在我自己的团队中，从去年3月份开始全面推行 Feature Branch + PR + Quality Gate 的方式，我们一直在持续改进这个过程。我们最希望做到是这样一种场景：

在这整个流程中，有一个关键环节就是在创建PR时动态的创建测试环境，我们希望每个PR都能够有独立的测试环境；因为PR对应到Feature Branch的代码变更，Feature Branch又对应到特定的用户故事，所以实际上我们的独立测试环境就对应到了特定的用户故事（需求）。我们就可以实现真正的端到端持续交付流水线。建立起用户故事（工作项）～ Feature Branch ～ PR ～ 环境 的完整持续交付链路，而且这个链路上的每个点都是和用户故事对应的。

想象一下，当你拉出分支提交了PR，马上就有一个和你的改动对应的环境进行测试，而且这个环境不会和其他分支的代码互相覆盖。团队清晰的知道当前的故事应该在哪个环境中测试，按用户故事进行规划，开发，测试和交付才真的落到实处。这绝对是向往的生活。

为了达到这个目的，我们利用了TFS发布流水线中的“控制选项”配合“环境变量”的功能来实现。

比如一下这个典型的多个并列（共享）的测试环境+一个生产环境的流水线。团队一共有3套服务器环境可以用来部署测试版本，也就意味着团队可以并行开发3个不同的用户故事，每个用户故事分别部署到自己独立的测试环境中，这个部署是通过PR上所配置的分支策略触发同一个构建定义来触发的。下图中左侧的“项目”部分已经绑定了这个构建定义做不部署拉取的Artifact的来源。

作为配置管理员，你需要确保每个团队清楚的知道自己现在所提交的PR正部署在那个环境中，那么这个团队就知道应该在哪个环境中测试自己的用户故事。这个映射可以通过以下环境变量完成。

以上的环境变量配置配置中，我们使用3个不同的环境中绑定了同一个变量名的不同变量值，这个变量都是ResourceGroupName （因为我们使用Azure作为我们的云环境，这个资源组名称就包含了一套可以独立部署和销毁的云环境，如果你不使用云环境，也可以把这个简单替换成一台服务器的IP地址），分别在3个环境中对应不同的名字

– TEST-ENV-01 使用资源组 YoTeamAspDemoApp5322Dev

– TEST-ENV-02 使用资源组 YoTeamAspDemoApp5322QA

– TEST-ENV-03 使用资源组 YoTeamAspDemoApp5322Prod

另外一组变量则将不同的Pull Request ID映射到这3个环境上，如下图你可以看到Pull Request 1,2,3分别绑定到了流水线中所定义的3个环境中。

最后，我们只需要使用流水线任务的控制选项就可以让流水线自动根据以上变量判断要部署的目标

在每个环境的Run on agent阶段上的其他选项中，选择 “使用变量表达式自定义条件”，并制定以下表达式

and(succeeded(), startsWith(variables['Release.Artifacts.YoTeamAspDemoApp5322-CI.SourceBranch'], variables['PullRequestID']))

注意这里所引用的2个变量：

variables[‘Release.Artifacts.YoTeamAspDemoApp5322-CI.SourceBranch’] 这个变量是TFS自动从触发CD的CI中带过来的用来标识分支的。当CI通过PR触发时，这里所带过来的就是PR的ref了。

variables[‘PullRequestID’]这个部分实际上就引用了我们之前定义的变量，这个变量在流水线运行中会自动赋予不同的值；

现在我们就可以通过更新环境变量中PR的ref值来制定PR所部署的环境了；触发以后的效果如下

你可以看到只有一个环境倍部署，其他的被跳过。

不过，这种实现方式并不够优雅，其实在TFS的流水线中已经包含了过滤分支的功能，但是当前版本(TFS 2018 U2)还不支持使用 PR 的 ref 值作为过滤条件。这个问题我们已经反馈给微软TFS开发团队，希望他们能够在后续的版本中提供。