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.



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

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

合作伙伴申请GTS失败的豁免请求并分配给android-waiver-request @。
android-waiver-request @分类错误并分配给Google测试所有者。






邮箱地址不会被公开。 必填项已用*标注