Release branch: Difference between revisions

From Regattadata
No edit summary
m (Changed protection level for "Release branch": Developer page (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite)))
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
=== RDS release ===
== Beta testing first! ==
 
Go to BETA TESTING FIRST


Update the version number in overrides/version.php
Update the version number in overrides/version.php
Line 11: Line 9:
Make sure your tree is up to date:
Make sure your tree is up to date:


  svn switch https://secure.regattadata.com/svn/trunk/rds
  svn switch https://secure.gavintech.com/svn/rds/trunk/rds
  svn update
  svn update
  svn commit
  svn commit
Line 17: Line 15:
Create a new release branch:
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
  svn cp https://secure.gavintech.com/svn/rds/trunk/rds https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-X_Y_Z


(replace X, Y, Z with version number)
(replace X, Y, Z with version number)


Switch over Beta on RDSWeb:
Switch over Beta on web1.gavintech.com:


  cd ../rds-beta
ssh richardcurry@web1.gavintech.com
  svn switch https://secure.regattadata.com/svn/branches/rds/release/X_series/sds-X_Y_Z
  cd /var/www/sites/secure.regattadata.com/pages/rds_beta
  svn switch https://secure.gavintech.com/svn/branches/rds/release/X_series/rds-X_Y_Z


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


  ../../sync_beta
  ../../sync_beta.sh


Run the migration script on RDSWeb:
Run the migration script on web1.gavintech.com:


  ./run_migrations.php (this updates the Beta database with any migrations necessary)
  ./run_migrations.php (this updates the Beta database with any migrations necessary)
Line 36: Line 35:
Email everyone who might care about the new release, and ask them to test the new version
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.
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 [[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)
  ssh richardcurry@web1.gavintech.com
  echo 'DROP DATABASE `sds-sandbox`' | mysql -u root -p
  cd /var/www/sites/secure.regattadata.com/pages/rds
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:
Copy the data to Beta for safety...


  cd /var/www/sds
  ../../sync_beta.sh
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.
Update the PHP scripts to the new version:


Then, merge the fixes back into the trunk (on your own checkout, not the production one!):
svn switch https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-X_Y_Z


svn switch https://sdsdev.smus.ca/svn/trunk/sds
Update the Production database with the changes
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).
./run_migrations.php


svn merge -r start-rev:end-rev https://sdsdev.smus.ca/svn/branches/sds/release/X_series/sds-X_Y_Z
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.


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


  svn commit -m 'merge in bugfixes from the release branch sds-X_Y_Z (revisions start-rev to end-rev)'
  svn switch https://secure.gavintech.com/svn/rds/trunk/rds
svn log https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-X_Y_Z


Then, update the SDS on the disaster recovery laptop to the same version as the production release
Look for the latest entry (which becomes end-rev) and the entry that mentions creating the release branch (start-rev).


On SDSData:
svn merge -r start-rev:end-rev https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-X_Y_Z


cd /var/www/sds
(fix any conflicts)
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
  svn commit -m 'merge in bugfixes from the release branch rds-X_Y_Z (revisions start-rev to end-rev)'
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

Latest revision as of 05:04, 24 September 2012

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.gavintech.com/svn/rds/trunk/rds
svn update
svn commit

Create a new release branch: 

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

(replace X, Y, Z with version number)

Switch over Beta on web1.gavintech.com: 

ssh richardcurry@web1.gavintech.com
cd /var/www/sites/secure.regattadata.com/pages/rds_beta
svn switch https://secure.gavintech.com/svn/branches/rds/release/X_series/rds-X_Y_Z

Copy over the production database to the beta database: 

../../sync_beta.sh

Run the migration script on web1.gavintech.com: 

./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 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): 

ssh richardcurry@web1.gavintech.com
cd /var/www/sites/secure.regattadata.com/pages/rds

Copy the data to Beta for safety... 

../../sync_beta.sh

Update the PHP scripts to the new version: 

svn switch https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-X_Y_Z

Update the Production database with the changes 

./run_migrations.php

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/rds/trunk/rds
svn log https://secure.gavintech.com/svn/rds/branches/release/X_series/rds-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/rds/branches/release/X_series/rds-X_Y_Z

(fix any conflicts) 

svn commit -m 'merge in bugfixes from the release branch rds-X_Y_Z (revisions start-rev to end-rev)'
Retrieved from "https://secure.regattadata.com/wiki/index.php?title=Release_branch&oldid=190"