Process for Setting Up Oracle Database for Cobalt Module

Ryan Morlok
Ryan Morlok ✭
in TR Internal
I've been recently working on setting up a new module on the Cobalt platform that is backed by an Oracle database. The administrative process for defining the database through requesting its deployment has not been especially clear. Could someone list out the steps and CRs required to get this into place? Also how hand off works between development, CM and Ops. Does the process change if the module is already deployed in PROD and the addition of the database is release dependent?
Tagged:

Best Answer

  • Lavanya Gundamaraju
    Lavanya Gundamaraju
    Answer ✓
    Good question Ryan. The development teams have taken a couple of differet approaches for setting up schemas in Dev environments. Either working directly with DBAs or by setting the schemas up by themselves and taking DBA feedback. In anycase, we CM like to be involved early in the game to make sure we understand what it takes to bring the new module up in the higer environments. 1. **CI** : Engage the DBAs to create the schema for the new module. Loop in CM so we know that there is a DB dependency for the module setup in upper environments. (Invite CM to the meeting with DBA - we will engange other parties as needed). Developers own the CI schemas. Once the schemas are created the developers can make any schema changes as they see fit 2. **Demo**: CM created the schema setup tickets for DBAs using the schema setup scripts provided by the developers. Any schema changes in Demo after the setup have to be communicated to CM before 2:00 PM everyday. Use appropriate database change request workitem in TFS Central (online:
    http://tfsnpt.int.thomson.com:8080/tfs/web/UI/Pages/WorkItems/
    WorkItemEdit.aspx?pguid=a26dfa46-07f4-435a-9801-ecc5393f39e9&wit=Db+Change+Request-Online). Please note that 2:00 PM is a hard deadline DBAs set for CM to ensure the schema changes are out there before the next day's demo deploy. *CM hosts DB schema change review meetings two times in the iterations where the developers and the DBA's participate to review the schema changes. Contact CO_CM_TECH if you need an invite to this meeting/conf call* 3. **QED and Up** - all schema changes are identified by the release.iteration identified in the database change request workitem. CM runs a query before each release to identify the list of schema changes across all modules and submit tickets for respectibe DBA teams Hope this makes sense.

Answers

Categories