Release branch: Difference between revisions

From Regattadata
m (Protected "Release branch": Developer page (‎[edit=autoconfirmed] (indefinite) ‎[move=autoconfirmed] (indefinite)))
Line 38: Line 38:
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.
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 ==
==New production release ==


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


On SDSData:
On web1.gavintech.com (or web2.gavintech.com):


  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)
  ../../sync_beta.sh
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/rds
 
  svn switch https://secure.gavintech.com/svn/branches/sds/release/X_series/sds-X_Y_Z
  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)
  ./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.
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 RDS 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!):
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 switch https://secure.gavintech.com/svn/trunk/rds
  svn log https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
  svn log https://secure.gavintech.com/svn/branches/rds/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).
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
  svn merge -r start-rev:end-rev https://secure.gavintech.com/svn/branches/rds/release/X_series/sds-X_Y_Z


(fix any conflicts)
(fix any conflicts)


  svn commit -m 'merge in bugfixes from the release branch sds-X_Y_Z (revisions start-rev to end-rev)'
  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

Revision as of 22:01, 20 July 2012

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 web1.gavintech.com (or web2.gavintech.com):

../../sync_beta.sh
cd /var/www/rds
svn switch https://secure.gavintech.com/svn/branches/sds/release/X_series/sds-X_Y_Z
./run_migrations.php (this updates the Production database with the changes)

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 RDS 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://secure.gavintech.com/svn/trunk/rds
svn log https://secure.gavintech.com/svn/branches/rds/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://secure.gavintech.com/svn/branches/rds/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)'