Parasoft CTP策略下发后为什么没有生效 Parasoft CTP策略版本该怎么回退

测试环境一切换，页面上给出保存成功的提示，并不代表目标服务已经在按新配置运行了，这个细节很多人在排查问题时容易忽略。Parasoft CTP对测试环境的管理，主要依赖环境定义、组件实例、变量、Virtualize资源以及Provisioning Action这几个模块一起来完成。团队里常说的“策略下发”，指的就是先把环境的配置保存下来，然后再去执行Provision动作，让配置里定义好的状态真正施加到目标环境上面去。官方文档也提到过，Environment Manager的用途正是把环境通过Provision操作，调整到测试所需要的指定状态。

一、策略下发之后为什么没有生效

发现配置没有生效的时候，不要只盯着页面里显示的变量值去看，因为很多情况下配置确实已经改掉了，但环境本身并没有被重新下发过。更有效的排查思路，是把保存、Provision、目标实例和Virtualize资源这几样拆开，分别检查一遍。

1、只做了保存，没有重新Provision

修改完环境变量、组件实例或者资源状态之后，还需要进到对应的环境里，把目标的Instance选好，然后再去点击【Provision】按钮。如果只是点了【Save】，大多数时候它只负责把配置存下来，不会自动去改动正在运行的环境。同样，如果是在流水线里跑任务，也要确认是不是已经执行过【Deploy an environment】这个步骤，而不只是把测试任务单独跑了一遍，少了这一步，环境的状态就不会被推送下去。

2、选错了环境的版本或实例

同一个System下面，可能会同时存在好几套Environment Version和Instance，比如常见的开发环境、集成环境、性能环境，它们之间是各自独立运转的。要是页面上改动的是这一套，实际测试时连接到的却是另一套，从结果上看就好像策略完全没有生效一样。所以在核对的时候，要把System、Environment、Version、Instance，还有目标Virtualize Server这几项信息放在一块对照着看，才能发现是不是连错了地方。

3、共享组件引起了配置的覆盖

CTP在复制环境的时候，提供了【Share】和【Duplicate】两种处理方式。如果选了Share，那么组件的配置会在相关联的几个环境版本之间共同使用，一旦修改了其中一处，就可能同时波及到其他的版本；如果选了Duplicate，那么组件实例和跟它关联的资源会被单独复制出来，修改的影响范围就更加独立。在环境之间需要做到相互隔离的时候，要留心别误用了共享组件的模式，不然很容易出现意外的覆盖。

4、目标资源并没有真正部署到位

Provision动作执行完之后，最好再去看一下Virtual Asset、Proxy还有Provisioning Action是不是全都已经成功运行了。实际当中，目标服务器说不定当时恰好离线了，或者登录的权限不够，也有可能是资源的存放路径发生了变化，还有代理端点之间存在冲突，这些情况都会造成页面上看起来配置正常，但运行时的状态其实根本没有更新。CTP自身在做Provision的时候，会自动检查资源有没有冲突，并且把可能会受影响的环境和端点一并提示出来，顺着这些提示往下排查，通常就能找出原因。

二、策略版本应当怎样回退

在CTP里面做回退，更稳妥的做法不是在当前环境里把变量一条条手工改成原来的值，而是提前就把可用的环境版本保留好。这样一旦出现什么异常，直接切回之前那个旧版本，再重新Provision一次就行了，既省时间，也不容易在改参数的时候出错。

1、复制一个可用的环境版本

先进到之前已经验证过的那个Environment里面，确定当前处于保存之后的状态而且是在编辑模式，接着打开页面上的操作菜单，找到【Copy】这一项。进行复制操作的时候，可以根据实际情况从【Share】、【Duplicate】或者【Ignore】当中选一个。按照官方文档的说明，复制完成之后的环境，会作为一个新的版本出现在Versions区域当中。

2、回退时直接切换到旧版本

需要回退的时候，先打开对应的System，在环境版本的列表里把原先能够稳定运行的那个旧版本找出来，再把里面的变量、组件实例和目标服务器的配置逐项核对一遍，然后去执行一次【Provision】。这里要记住，不能只是把页面上的显示切换回旧版本就觉得已经完事了，真正要让旧的配置生效，还是需要靠重新下发一次环境的状态。

3、把有风险的资源隔离开来

当新的环境版本当中动到了Virtual Asset、Proxy或者Provisioning Action的时候，更推荐的做法是使用Duplicate的方式来复制环境。因为这样一来，新的改动就不会直接传递到旧的版本那边去，等到需要回退的时候，也不容易出现旧环境其实早已被一块改过的情况，排查起来就会简单不少。另外，如果是把环境复制到别的Virtualize Server上使用，也可以顺手把复制相关资源和下发动作的选项给勾上，让整个迁移过程更完整。

三、怎样减少策略变更带来的返工

每次对策略做变更，都应该留下以后能够回来查找的记录，否则等环境数量慢慢多起来以后，再想弄清楚到底是哪一次改动引起了问题，就要花上很多的排查时间。

1、每次变更时把版本信息写清楚

可以在环境名称或者version变量里面，把用途、改动日期和这次变更大致涉及的范围都标注出来，比如标明是给集成测试用，是做接口联调，还是为了性能验证而建的。尽量不要在同一个环境版本上反复进行覆盖式的修改，那样的话历史记录会全部缠在一起，很难再找到当时的准确状态。

2、下发之后先做一轮简单验证

Provision顺利跑完之后，可以先快速地确认一下目标服务的状态、代理端口的响应，还有变量的实际取值是不是正常，再挑一两条有代表性的接口跑一下试试。等到这些轻量级的检查都已经通过了，再去启动完整的测试任务，这样就能避免大批量的用例都跑完了，才发现测试环境根本就没切过来的窘况，因为那种情况下既浪费时间，又很难追溯问题。

3、在流水线里把执行记录保留好

如果已经通过Jenkins这类工具把CTP接入了流水线，控制台输出里面通常就能看到环境下发的过程进度和最终结果。按照官方插件说明的思路，也可以通过构建历史里的进度条，或者是Console Output页面，去查看更加详细的执行状态。把这些记录保存下来，以后在追踪问题的时候，就是很直接的查询依据了。

总结

Parasoft CTP策略下发之后为什么没有生效、策略版本又该怎么回退，排查的时候要先确认是不是已经重新Provision过，再去核对环境的版本、实例、共享组件，以及目标资源当时的状态。回退的时候，尽量采用提前复制好的旧版本，不要临时靠手工去改参数。同时，把版本命名的习惯、资源隔离的方式、下发之后的验证动作，还有流水线的执行记录这几样事情固定下来，整个测试环境的切换和变更过程，就会比之前清晰很多，也能在很大程度上减少不必要的返工。