| 67 | | Test away and, if necessary (because several developers are working on the site, or you are preparing a large release) repeat the process on the TEST server... |
| | 76 | '''4b. Backup & put Drupal into maintenance mode''': You are now ready to take the site down and get the new files onto the server, but first you need to make a backup and prepare in Drupal... |
| | 77 | 1. Log in as Transition Admin (user 1 - password available on request) |
| | 78 | 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. |
| | 79 | 1. Go to 'Site building' -> 'Backup & migrate' and make a manual backup of the database - saved on the server. |
| 70 | | |
| 71 | | 1. OPTIONAL: points 1-5 happen as many times as required to get the release ready, tested and signed off. |
| 72 | | 1. Developer backs up and updates LIVE using the latest tagged release. NOT USING MERGE!!! Using 'svn switch' in our case. If there is a problem the developer can always switch back to the previous tagged release for LIVE and examine the issue in TEST. |
| 73 | | |
| 74 | | == Comment from Chris == |
| 75 | | |
| 76 | | Some suggestions: |
| 77 | | |
| 78 | | Developers work on the browser:www/trunk and this is tested on [http://test.transitionnetwork.org/ test.transitionnetwork.org] and [http://dev.transitionnetwork.org/ dev.transitionnetwork.org] as required. |
| 79 | | |
| 80 | | When the code is ready to be deployed to the live server it's tagged, which is an svn copy, eg: |
| 81 | | |
| 82 | | {{{ |
| 83 | | svn cp trunk rel-2010-11-19 |
| 84 | | svn commit -m "Release version 2010-11-19" |
| 85 | | }}} |
| 86 | | |
| 87 | | Then on the live server this is deployed: |
| 88 | | |
| | 83 | '''4c. Deploy the new code''': Back in the terminal where you are SSHed into the correct machine AND in the correct site root folder... |
| | 88 | Using your release date, obviously. After a short while the server will complete the task and you can... |
| | 89 | |
| | 90 | '''4d. Finish the job''': Go back to Drupal in your browser and... |
| | 91 | 1. Go to the 'Database update' page at http://www.transitionnetwork.org/update.php (or test.transitionnetwork.org/update.php) and complete the process. |
| | 92 | 1. Go to the homepage, initiatives directory, blogs etc and check the site is looking and behaving like it should. If it isn't you will need to fix the issue. If you can't you will need to roll back - see the next section. |
| | 93 | 1. Repeat the update process on the Workspaces subdomain. |
| | 94 | 1. Go to 'Site configuration' -> 'Site maintenance' and put the back main site online. And the Workspaces sub-site. |
| | 95 | 1. Let everyone who needs to know the site is back and updated. Then have a beer. |
| | 96 | |
| | 97 | === 5. Rolling back a release === |
| | 98 | 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: |
| | 99 | 1. (Assuming you can still use Drupal) Take the site back offline and go to 'Site building' -> 'Backup & migrate' -> 'Restore' |
| | 100 | 1. Restore the database backup just prior to the and make a manual backup of the database - saved on the server. |
| | 101 | |
| | 102 | (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 }}}) |
| | 103 | |
| | 104 | Once the database is back, WITHOUT doing anything more in Drupal, switch the files back: |
| | 105 | {{{ |
| | 106 | sudo -i |
| | 107 | svn switch https://tech.transitionnetwork.org/svn/www/release/[the previous release]/ . |
| | 108 | }}} |
| | 109 | That's the files back so clear the caches and test the site. |
