GPS 更新豁免流程

GTS updated waiver approval process

 

We introduced Business Logic (BL) based tests as Partner Agreement Enforcement System in GTS 6.0 R1 release in July, 2018.  All Business-logics are hosted on Google servers and can be updated and pushed to production as and when required. This also gives the advantage that partners no longer need to wait for another GTS release to get the fixed test. After the fix is applied on production, a partner can rerun the test and get the test pass.

Hence, therefore, we have decided that we will not be approving any GTS waiver requests for such BL based GTS test failures. The step-by-step process for waiver approval process for GTS BL failures looks like this:

1. Partner apply for waiver request for GTS failure and assign to android-waiver-request@.
2. android-waiver-request@ triage the bug and assign to Google test owner.
3. If the issue is in BL side, the Google test owner fixes the issue and deploy on production.
4. Bug is assigned to partner to rerun the test.
5. Once the partner confirms the fix by passing the test, the partner can upload the passing GTS to APFE and close the bug.

The process for Java based GTS test failures will remain as it is (since that requires another GTS release to get the fixed test to the partners). We understand that, a partner may not be able to distinguish a Java based test from a BL based test. Hence, we kept the initial waiver request process (#1) as same.

We have introduced staging environment to test out the rules before pushing the changes to production as our enhanced internal testing process. This is to reduce any outages happening because of any erroneous change.

 

GTS更新了豁免审批流程

我们在2018年7月的GTS 6.0 R1版本中引入了基于业务逻辑（BL）的测试作为合作伙伴协议执行系统。所有业务逻辑都托管在Google服务器上，可以根据需要进行更新并推送到生产环境。这也使合作伙伴不再需要等待另一个GTS版本来获得固定测试。在生产中应用修复后，合作伙伴可以重新运行测试并获得测试通过。

因此，我们已经决定，我们不会批准任何GTS豁免申请此类基于BL的GTS测试失败。 GTS BL故障豁免审批流程的逐步流程如下所示：

合作伙伴申请GTS失败的豁免请求并分配给android-waiver-request @。
android-waiver-request @分类错误并分配给Google测试所有者。
如果问题出在BL方面，Google测试所有者会修复问题并在生产中进行部署。
错误被分配给合作伙伴以重新运行测试。
一旦合作伙伴通过测试确认修复，合作伙伴可以将传递的GTS上传到APFE并关闭错误。
基于Java的GTS测试失败的过程将保持不变（因为这需要另一个GTS版本才能将固定测试发送给合作伙伴）。我们理解，合作伙伴可能无法将基于Java的测试与基于BL的测试区分开来。因此，我们将初始豁免请求流程（＃1）保持不变。

我们引入了临时环境来测试规则，然后将更改推送到生产中作为增强的内部测试流程。这是为了减少由于任何错误更改而发生的任何中断。