Data Bug处理流程

目前正在做的项目，是我从未遇到过的类型。面临的挑战也是前所未有的，吐槽自然是免不了，但我还是尽量控制一下，少说废话

介绍一下背景，这个平台已经有十几年的开发历史，体系庞大，业务繁杂，光代码就20G+，N个Branch。文档更新也不及时，有时你看的是十年前的东西。我们组负责的是Financial Report部分。作为这个项目的测试，花时间最多的工作是自己看存储过程了解业务，理解Bug；再Review开发提供的代码/脚本。相信经过这个项目，我的T-SQL，PowerShell方面的技术都会有所提高。

我们处理的大部分是数据问题，Data Fix嘛，可大可小的。钱的问题，发票的问题，全世界人民的态度都是一样敏感的。以下四点显得格外有意义――

1.数据库表都应该有dt_updated_time和nvc_updated_by字段

例如：

dt_updated_datetime = GETUTCDATE()

nvc_updated_by = 'Bug#81197'

2.Bug除了有Status之外，还应该有Sub-Status

Active

|- 0-Not Started

|- 1-Under Investigation

|- 2-Working on Fix

|- 3-Testing Fix

|- 4-Fix ready

|- 5-Fix Submitted

Resolved

Closed

3.Code review sign-off，dev sign-off和test sign-off

4.Ship Room Process
所谓Ship room（SR），就是上头任命了几个人搞了个委员会的形式，在部署之前，要把一群人叫到房间里开会。逐个逐个地过Bug，那些‘委员’会提各种问题，明确Bug以及改动带来的影响，做最后决定是否部署。看似是个很形式化的东西，但是既然它以项目之外第三方的形式出现，就逼着开发和测试要在Ship room之前对Bug做好全面分析。压力不小

我们严格遵守下面的Data Bug处理流程。

Common

Add SR Template when you are assigned a new bug. Spend around 15 minutes and add Impact as the first thing and other information we can keep adding as we make progress with the fix.

Data bugs

Hotfix (Prod P0 or P1 bugs)

Create data fix RFC in your private share
Send above path for Code review and Test signoff
Once CR and Test signs off, Test owner will attach the RFC to PS bug
Dev and Test both needs to add “Sign off” in the Description field in PS bug.
Ask PM to Create RFC and get Ops sign off (again in the Description filed in the bug)
Add “Review” keyword and Triage will mark it for Shiproom approval.
Once SR approved, Resolve the bug and let PM know and he/she will create a P1 Change request.
PM will copy the RFC package only from PS bug and attach it to the Change request (or drop to right location for Ops).
Once the RFC is deployed in Prod, Test owner will verify the results and Close the bug.

CWR (Prod P2 or P3 bugs)

Create data fix RFC in your private share
Send above path for Code review and Test signoff
Once CR and Test signs off, Test owner will attach the RFC to PS bug
Dev and Test both needs to add “Sign off” in the Description field in PS bug.
NO need to get Ops sign off for CWR bugs.
Add “Review” keyword and Triage will mark it for Shiproom approval.
Once SR approved, Resolve the bug and let PM know and he/she will create a Weekly Change request.
PM will copy the RFC package only from PS bug and attach it to the Change request (or drop to right location for Ops).
Once the RFC is deployed in Prod, Test owner will verify the results and Close the bug.

CMR

Ideally we should not have data bugs in CMR release J
But there might be cases for adding data to Domain tables, in which case follow the same process as CMR Code bug fix (see below)

Appendix

--------------------------------

Shiproom Template:

--------------------------------

1.Summary

2. What is the fix

3. Fix impact

4. Cost in days (Dev/Test)

5. Linked bugs:

a. Root cause: <bug #>

b. Other customers that are/might be impacted with this issue: <bug #>

c. Monitoring (if required): <bug #>

d. Deployment bug: <bug #>

6. Risk (L/M/H, please also call out any concern)

7. Lockdown Signoffs: (Dev Lead, Test Lead, PM Lead)

8. Code review Sign off:

9. Test Sign off:

10. Ops Sign off: <this is required mainly for P1/hotfix deployment>

11. Code review url: <codeflow url>