| 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 === |
| | 5 | The primary focus should be on supporting the SysAdmin whose job it is to keep production servers running. |
| | 6 | |
| | 7 | They 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 | |
| | 9 | They 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 | |
| | 11 | Priority tasks for them: |
| | 12 | 1. They want a report on the potential data migration issues they may face |
| | 13 | 1. 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. |
| | 15 | 1. 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 | |
| | 18 | One 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 === |
| | 37 | A 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 ==== |
| 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 ==== |
| | 45 | 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. |
