Release branch

RDS release

Go to BETA TESTING FIRST

Update the version number in overrides/version.php

Update the changelog in overrides/front_page_news.php

Send out last call to the RDS developers a few hours before making the branch

Make sure your tree is up to date:

svn switch https://secure.regattadata.com/svn/trunk/rds
svn update
svn commit

Create a new release branch:

svn cp https://secure.regattadata.com/svn/trunk/rds https://secure.regattadata.com/svn/branches/rds/release/X_series/sds-X_Y_Z

(replace X, Y, Z with version number)

Switch over Beta on RDSWeb:

cd ../rds-beta
svn switch https://secure.regattadata.com/svn/branches/rds/release/X_series/sds-X_Y_Z

Copy over the production database to the beta database (on SDSData):

../../sync_beta

Run the migration script on RDSWeb:

./run_migrations.php (this updates the Beta database with any migrations necessary)

Email everyone who might care about the new release, and ask them to test the new version

Make fixes directly to the release branch. We'll merge bugfixes back into the trunk when the new version goes live on production. Note any fixes in the SDS_Changelog for that version, and also in the overrides/front_page_news.php file.

NEW PRODUCTION RELEASE

After confirming that the new release works (give it about a week), go live with production:

On SDSData:

mysqldump -u root -p sds | 7za a -t7z -m0=lzma2 -si sds-`date +%d%b%Y`.sql.7z (in case something screws up with the migration)
echo 'DROP DATABASE `sds-sandbox`' | mysql -u root -p
echo 'CREATE DATABASE `sds-sandbox`' | mysql -u root -p
7za e sds-`date +%d%b%Y`.sql.7z -so 2> /dev/null | mysql -u root -p sds-sandbox

On SDSWeb:

cd /var/www/sds
svn switch https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
sudo /etc/init.d/memcached restart (this ensures that old data isn't cached)
./run_migrations.php (this updates the Production database with the changes)
sudo /etc/init.d/memcached restart
sudo /etc/init.d/sds stop
sudo /etc/init.d/sds start

After you've run the migrations, go to the auditing portal page (Admin->Security->Auditing Portal) and click the "Mark all scripts as tested" button so that the production SDS has up to date hashes. That way, we can tell what files have changed when we start preparing the next release.

Then, merge the fixes back into the trunk (on your own checkout, not the production one!):

svn switch https://sdsdev.smus.ca/svn/trunk/sds
svn log https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z

Look for the latest entry (which becomes end-rev) and the entry that mentions creating the release branch (start-rev).

svn merge -r start-rev:end-rev https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z

(fix any conflicts)

svn commit -m 'merge in bugfixes from the release branch sds-X_Y_Z (revisions start-rev to end-rev)'

Then, update the SDS on the disaster recovery laptop to the same version as the production release

On SDSData:

cd /var/www/sds
sudo svn switch https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
sudo /etc/init.d/sds stop
sudo /etc/init.d/sds start

On JRCups:

cd /var/www/sds
sudo svn switch https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
sudo /etc/init.d/sds stop
sudo /etc/init.d/sds start

Update sandbox on SDSWeb:

cd /var/www/sandbox
sudo svn switch https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
sudo /etc/init.d/memcached3 restart (this ensures that old data isn't cached)
sudo ./run_migrations.php
sudo /etc/init.d/memcached3 restart