wiki:PakistanDeploymentCycle

Version 44 (modified by Fran Boon, 11 years ago) ( diff )

--

Pakistan Deployment Cycle

Process

We do daily upgrades of the systems from a single Fabric script:

  1. Upgrade Live with code release from UAT
  2. Refresh the UAT database with data from Live
  3. Upgrade UAT to Trunk code
  4. Send a notification to the List with a summary of the changes on both Test & Live

Instructions

Login to eden.sahanafoundation.org

1st time:

cd /home/release
fab generate_keys
fab test distribute_keys
fab prod distribute_keys

Subsequently:

cd /home/release
fab prod deploy
fab test deploy

Make a note of any upgrade issues with the migration on Test so that they can be streamlined in tomorrow's migration on Live

Sysadmin ToDo

1. Upgrade Live with code release from UAT

  • Read VERSION from UAT to know which revision to pull to live
  • pull
    • the 'update' script falls back to 'bzr pull' but supports an 'update XXX' arg to 'bzr pull -r XXX'
  • check for conflicts & copy all .THIS over (either parse the bzr output or search filesystem - whichever is easier/quicker)
  • migrate (CLI web2py load as 'su web2py')
  • check for migration failures in databases/sql.log
  • resolve any migration failures
    • we should be able to have a script developed during the UAT upgrade to do this automatically
  • migrateoff

2. Refresh the UAT database with data from Live

  • Include 'uploads' folder
  • Need to ensure that User Accounts in Test are not overwritten
  • Need to ensure that Role memberships in Live & Test can be different
    • Maybe add generic role accounts in a script after the DB replaced?

3. Upgrade UAT to Trunk code

  • pull
  • check for conflicts & copy all .THIS over (either parse the bzr output or search filesystem - whichever is easier/quicker)
  • migrate (CLI web2py load as 'su web2py')
  • check for migration failures in databases/sql.log
  • resolve any migration failures
    • let user know which table failed (in sql.log)
    • launch a mysql prompt with 'show innodb status;' (parsed?)
    • potentially even have mysql fix it automatically (possible for sure, but lower priority than the core)
  • migrateoff

4. Send a notification to the List with a summary of the changes on both Test & Live

Notifications can be built with info from the Trac Timeline

General

  • Set deployment_settings on UAT to the same as Prod
  • Add rollback() by reading VERSION before bzr pull, so then can bzr revert -r $version
  • Add update() for debian packages: SSH into each & apt-get update; apt-get upgrade
  • Enhance Apache Maintenance site
    • allowing access to site through a browser - but using a different name (which we don't publish)
      /etc/apache2/sites-available/maintenance
      
    • improving the text on the maintenance page: /var/www/maintenance.html
  • Create a new dev.pakistan.sahanafoundation.org instance
    • This shouldn't be fully-automated into the upgrades cycle, but does have a script to refresh data from live manually

Live

  • Get MapProxy working (basic install on 'geo' done)

Demo

  • Update Demo (whilst keeping the logins there intact - all other data can be dropped)

Trac

  • Investigate a fix or alternative to http://trac-hacks.org/wiki/MathCaptchaPlugin for allowing Trac users to register bugs anonymously whilst not locking out our testing team.
  • Convert from sqlite to PostgreSQL (or MySQL) to improve performance

UserGuidelinesUpgrade

DeveloperGuidelinesDataMigration

Pakistan

Note: See TracWiki for help on using the wiki.