5 - Database Change Process

INTRODUCTION

This process has been created to formalize the communication within the broader CTS/WBD team when database schema, field, or usage changes are made.

APPLIES TO

• Application Developers
• Reporting Team

OBJECTIVE

Team communication process to prevent the introduction of errors in production reports resulting from database changes.

PROCESS

1. When a developer makes a change to the database schema, database fields, or how the database is used, they must inform Victor.  These changes include, but are not limited to, changes to a database field and changes to the way an application form records in the database to a new table.  
2. Victor will then do the following:
   • Create a FogBugz case with the following naming convention
     • DB CHANGE: [Database Table Name], [DATABASE FIELD NAMES]
   • Place the cases in the "In Progress" field on the Kanban board
   • Give the case a Kanban color of RED
   • Assign the case to Brock and notify DB
3. Brock will then do the following:
   • Ensure that the on-shore development team (Jonathan / Mark) review the case.  Each developer will comment on the case indicating that they have review it for broader system impact.
   • Ensure that  each report developer review the database change.  Each developer will comment on the case indicating that they have reviewed the change for impact on current reports.
   • Brock will comment on the case as well confirming his review.
   • If the database change impacts a report or process, the developer responsible for that report or process will open a case to address the problem.  The new case will be a child of the DB Field Change Case.
4. Once all relevant parties have reviewed the case, Brock will close the case in FogBugz and notify Victor that the review is complete.