Changes between Version 5 and Version 6 of CodeManagementReleaseProcessOld

Timestamp:

11/23/10 14:03:34 (6 years ago)

Author:

chris

Comment:

--

CodeManagementReleaseProcessOld

@@ -12 +12 @@
  1. You '''never hack Drupal core'''
  1. Developers work on their own machines and check into the DEV branch of the SVN repository (viewable here: browser:www/trunk) ONLY when their code TESTED functional.
- 1. The development server (DEV) mirrors the LIVE environment must be used to test this code before moving to LIVE.
- 1. There is a TEST server which can also be used as required, but is optional unless there is a lot of development work going on or many developers need to test their work in preparation for a release to LIVE.
+ 1. The [http://dev.transitionnetwork.org.webarch.net/ development server (DEV)] mirrors the LIVE environment must be used to test this code before moving to LIVE.
+ 1. There is a [http://test.transitionnetwork.org.webarch.net/ TEST server] which can also be used as required, but is optional unless there is a lot of development work going on or many developers need to test their work in preparation for a release to LIVE.
  1. The LIVE server ONLY EVER gets tagged releases put on it. Such releases must be tested (both on a local developer machine AND on DEV) prior to release. Hence, the LIVE server moves from one tagged release to the next.
- 1. Database backups must happen before each release to LIVE - this way each release on LIVE has an associated database backup.
+ 1. Database backups must happen before each release to LIVE - this way each release on LIVE has an associated database backup. Go to 'Site building' -> 'Backup & migrate' (or use the command line NewLiveServer#mysql-backup script) to create the backup.
+ 1. You can update the test and dev site's databases and files to match the live server using the DevelopmentServer#live2dev script.
 
 == Software & Getting Started ==
@@ -58 +59 @@
 
 === 3. 'Tag' (copy) the release ===
-Once everyone is happy with the DEV site updates, you will need to 'tags' (svn copy) the release so it's ready to be moved onto the LIVE server - or the TEST site if needed (more on that in a moment).
+Once everyone is happy with the DEV site updates, you will nee/root/.my.cnfd to 'tags' (svn copy) the release so it's ready to be moved onto the LIVE server - or the TEST site if needed (more on that in a moment).
 
 You need to SSH into the DEV server and go to the website root folder (as above). Then run these commands to tag the release:
@@ -77 +78 @@
  1. Log in as Transition Admin (user 1 - password available on request)
  1. Go to 'Site configuration' -> 'Site maintenance' and put the site offline. Ideally update message so users can see when the site is likely to be back - allow 15 minutes.
- 1. Go to 'Site building' -> 'Backup & migrate' and make a manual backup of the database - saved on the server.
+ 1. Go to 'Site building' -> 'Backup & migrate' (or use the NewLiveServer#mysql-backup script) to make a manual backup of the database - which is saved on the server.
 
 '''NOTE''' you will need to do points 2 and 3 above on the http://workspaces.transitionnetwork.org domain too!
@@ -97 +98 @@
 === 5. Rolling back a release ===
 If it goes badly, don't panic. You have all the old code in SVN and a snapshot of the database just prior to updating it. To roll back, run the following commands on the server you're logged into:
- 1. (Assuming you can still use Drupal) Take the site back offline and go to 'Site building' -> 'Backup & migrate' -> 'Restore'
+ 1. (Assuming you can still use Drupal) Take the site back offline and go to 'Site building' -> 'Backup & migrate' -> 'Restore' (if the NewLiveServer#mysql-backup script has been used then the restore will have to be done via the command line).
  1. Restore the database backup just prior to the and make a manual backup of the database - saved on the server.
 
-(If you can't use Drupal you will need to use the command line to restore the database backup you made. Essentially this consists of going to the sites/default/files folder and getting the database snapshot file you made, then running a command similar to {{{ mysql -u username -p -h localhost data-base-name < data.sql }}})
+If you can't use Drupal you will need to use the command line to restore the database backup you made. Essentially this consists of going to the {{{/web/transitionnetwork.org/www/sites/default/files/backup_migrate/manual}}} folder and getting the database snapshot file you made (or /var/backups/mysql/ if the NewLiveServer#mysql-backup script was used, note this script backups up all the databases not just the Drupal one), then running a command like:
+
+{{{ mysql live < TransitionNetwork-TransitionAdmin-2010-07-05T11-08.mysql }}} 
+
+If you do this as root you don't need to specify the host, user or password as they will be read from {{{/root/.my.cnf}}}).
 
 Once the database is back, WITHOUT doing anything more in Drupal, switch the files back: