我处于一个令人困惑的情况，我为WordPress开发插件并将它们推送到我的git存储库。 WordPress在AWS服务器上，每次推送到git，我都必须创建一个具有弹性beanstalk的新环境。
一旦我推送到git，我首先创建一个DEV环境并将我想要推送到生产的更改拉出来。防爆。我有变化：c1，c2，c3，c4，c5，我想推c1，c2，c3。我拉动更改并创建DEV。然后我创建测试环境进行测试。一旦通过，我创建UAT（客户测试环境）。假设客户不喜欢c3，并要求我们只推c1和c2。在这种情况下，我必须重新创建DEV，TEST和UAT环境并重新测试，因为删除c3也可能会影响其他代码。我必须将代码发送到UAT，因为那时我重新打包了代码，因此需要一个新的UAT。
我正在寻找一种方法来减少我向UAT发送相同代码的次数。从技术上讲，我不应该再向UAT发送相同的代码。
我正在考虑单独推动每项改变而不是将它们包装在一起;这将消除UAT中的冗余，但会为测试团队增加更多的工作，这将导致瓶颈。
PS。我无法创建自动化测试，因为更改主要是关于图形和视觉效果。此外，还有数千页要测试。为一切编写测试脚本是没有意义的。有什么建议吗？
答案 0 :(得分：1)
从技术上讲，您并未向UAT发送相同的代码：在c3拒绝后，您发送回c1+c2，而不是c1+c2+c3 - 不是相同的代码。
不幸的是，使用基于提交后验证的集成解决方案，没有一种确定的方法来最小化UAT提交的数量。这是因为您无法提前知道哪个提交会导致UAT拒绝。
正如您所注意到的，最可预测的前进方式也是成本最高的 - 为每次更改运行UAT。减少UAT提交的唯一方法是提交捆绑在一起的多个更改 - 捆绑越大，UAT提交越少。但是这引发了一个冲突：UAT失败的可能性也随着捆绑大小的增加而增加，识别罪魁祸首所需的二分重试次数也是如此（假设每个捆绑中只有一个，如果有几个，那么它更糟糕。）
我在最近2-4周内对UAT提交进行分析，并确定UAT拒绝的概率达到30-50％，然后选择最大功率低于该值的2（对于您在失败时需要执行的二分法更好）。比如说，分析表明值为5，然后选择4作为束大小。
如果你没有足够的更改来填充捆绑包，我建议再次选择2的最大功率，剩下的则用于下一个捆绑包 - 其他更改可能会在平均时间内合并，也许你可以填写下一个包。除非您已经知道变更集之间的依赖关系，这些依赖关系需要它们在同一个捆绑中，并且可能会让您处于首选值之间。如果您选择让所有这些依赖项（更高的风险）为下一个捆绑包，那么由您决定。
您还应该继续监控捆绑包大小与UAT拒绝趋势的可能性（产品和UAT的演变，事情发生变化） - 您可能需要不时调整首选捆绑包大小。
副注释：您始终可以构建一些自定义UAT包装器脚本，使其显示为可以连接到CI / CD管道的自动化测试。只有它具有不确定的队列等待和/或执行时间。并且，如果它的执行确实是手动的，那么它也可能更不可靠。