Changes between Version 2 and Version 3 of BluePrint/DatabaseMigration


Ignore:
Timestamp:
06/16/12 11:09:39 (9 years ago)
Author:
Fran Boon
Comment:

SysAdmin Workflow

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/DatabaseMigration

    v2 v3  
    22[[TOC]]
    33== Work Flow ==
    4 === Developer Who does the changes in his branch ===
    5 {{{
    6 #!html
    7 <p class="MsoNormal" style="margin-bottom: .0001pt;"><span style="font-size: 12.0pt; line-height: 115%; font-family: 'Garamond','serif';">
     4=== Primary: SysAdmin ===
     5The primary focus should be on supporting the SysAdmin whose job it is to keep production servers running.
     6
     7They have a live system with live data & new code whose impact on the live data they are unaware of (we assume that the actual code has been tested separately with new data).
     8
     9They cannot trust that developers have done the right thing & given them all the correct hints (although would like to be able to make use of any which are provided).
     10
     11Priority tasks for them:
     121. They want a report on the potential data migration issues they may face
     131. If it canot be migrated automatically, then they would like assistance with building a migration script
     14 * The boilerplate should be in-place and the tables with issues should have sections with as much automated migration code done as possible.
     151. Once the script has been written, they'd like to run this on a copy of their live database to check that the migration goes smoothly & then they can run user-testing on the test system (with new code/migrated data) before upgrading the live production system.
     16 * If this can be run automatically then so much the better
     17
     18One way to achieve this would be to:
     19* create a new web2py application folder (e.g. {{{web2py/applications/test}}})
     20* copy the old code/settings into this new folder
     21* modifiy the settings in the new folder to change the DB name (e.g. 'sahanatest')
     22* create the new DB in the OS
     23 * assume that localhost postgres sites can sudo postgres
     24 * assume that MySQL sites have a .my.cnf setup for OS-level root access
     25* dump the live DB
     26* import into the test DB
     27* checkout the new code into the new application
     28* calculate the ability of the system to do an automatic migration
     29 * [http://web2py.com/books/default/chapter/29/6#Gotchas database-speciifc issues with Web2Py's automatic migration]
     30* if OK, then do the migration & let the users test
     31* if not OK, then build a migration script
     32* if confident that the migration script is complete, then do the migration & let the users test
     33* if not confident, then let the SysAdmin complete the migration script, which they then run manually
     34* when the SysAdmin is confident that the migration has been tested sufficiently, they run the script with a different command line option to migrate the live system
     35
     36=== Secondary: Developer ===
     37A secondary focus would be on supporting developers to provide hints to the SysAdmin about what how the migration should be done:
     38==== Developer Who does the changes in his branch ====
    839There would be a view that shows the Database Migration Screen (as explained below) . There would be folder in models which will be loaded only when this view is called . This model will have the comparing script that track schema changes ( as explained below ) . This script will compare the current database( the version which merger is about to push or merge to the trunk),  with the DAL instance serialized (which will be made part of the trunk).
    9 <br />
    10 <br />
    11 <b>Thus whenever the merger runs this view a migration script is generated which is stored in the Database folder along with the Current DAL instance serialized which is used for future mergers .
    12 <br />
     40
     41Thus whenever the merger runs this view a migration script is generated which is stored in the Database folder along with the Current DAL instance serialized which is used for future mergers .
     42
    1343Thus 2 extra things will be stored in the Database folder in the trunk too. Thus whenever somebody pulls from the trunk this current DAL instance he pulled shall be used to compare with the changes he do in the future
    14 </b>
    15 <br />
    16 <br />
    17 </span></p>
    18 }}}
    19 === SysAdmin (The Person who entertains the pull request from the developer to merge the code in the trunk)===
    20 {{{
    21 #!html
    22 <p class="MsoNormal" style="margin-bottom: .0001pt;"><span style="font-size: 12.0pt; line-height: 115%; font-family: 'Garamond','serif';">
    23 
    24 This is active at the time the pull request is entertained by the sysadmin who merges with the trunk. Thus he need to travel from commit t to commit k . There can be git hooks attached with the "git pull" which will make the migration script present in the revision (provided by developer ) run . If any discrepancies are found between the schema changes and the migration script suggested by the developer thus the data cannot be migrated , then we would inform the sysadmin about the problem sysadmin is then presented the migration script to customize to requirements needed . This can be done all the way from commit t to commit k .
    25 
    26 }}}
     44==== Merger to Trunk ====
     45This is active at the time the pull request is entertained by the sysadmin who merges with the trunk. Thus he need to travel from commit t to commit k . There can be git hooks attached with the "git pull" which will make the migration script present in the revision (provided by developer ) run . If any discrepancies are found between the schema changes and the migration script suggested by the developer thus the data cannot be migrated , then we would inform the sysadmin about the problem sysadmin is then presented the migration script to customize to requirements needed . This can be done all the way from commit t to commit k.
    2746
    2847== Tracking Schema Changes ==
     
    162181<p class="MsoListParagraph" style="margin: 0cm; margin-bottom: .0001pt;"><span class="apple-style-span"><span style="font-size: 12.0pt; line-height: 115%; font-family: 'Garamond','serif';">&nbsp;</span></span></p>
    163182}}}
     183
     184== See Also ==
     185* [http://web2py.com/books/default/chapter/29/6#Gotchas database-speciifc issues with Web2Py's automatic migration]