Drumbeat Application Environments

1. Development Server ("Dev")

1.1 Initial staging environment for Drumbeat application.

1.2 Contains working copy of code with sample data.

1.3 Currency of the data is rarely important, only needs to be updated when major code changes occur.

1.4 Used primarily as a common place for developers to stage changes prior to submitting them for testing in staging.

1.5 No physical location yet - lives on Trellon's servers for now.
http://drumbeat.trellon.org/dbl/

2. Staging Server ("Staging")
http://drumbeat.stage.mozilla.com/

2.1 Pre-production staging environment for Drumbeat application.

2.2 Contains working copy of code with sample data mirrored from live.

2.3 Used for testing changes to production environment.

2.4 Data is mirrored nightly, contains a copy of live data.

2.5 Access is limited to people with commit privileges for live.

3. Production Server ("Live" or "Production")

3.1 Production environment for Drumbeat application.

Moving from Dev to Staging

Deployments to staging are deployed in a series of steps, in order of decreasing rarity. We check out code, modify any content type settings, modify any views settings, modify any Drupal settings, modify any file settings, then run any scripts to conduct mass data changes.

1. SVN CHECKIN

1.1 Code gets checked into svn for deployment on staging.

1.2 All code updates must be stored in SVN in order to make their way to staging. Obvious, but this should be explicit.

2. CODE

2.1 Code gets checked out on staging via svn.

2.2 The only code that gets checked out is referenced by a specific ticket. Any other modifications are left in svn.

3. CONTENT TYPES

3.1 Content type changes are exported from dev to staging via the Content Copy module. 3.2 The content type definitions are copied manually by a user from dev to staging.

3.3 Content copy will modify any existing content types to add fields. Data translation may be required.

4. VIEWS

4.1 Views are exported from dev to staging manually using views export.

4.2 Existing views with the same name are deleted from staging.

4.3 Views being imported are pasted into the import form and are now live on staging.

5. DRUPALSETTINGS

5.1 Any modifications to settings in Drupal are made at this point.

6. FILE SETTINGS

6.1 Any modifications to files - such as paths in civicrm.settings.php - are made at this stage.

7. OTHER SETTINGS

7.1 Any mass modifications to data should be contained in a script.

7.2 Scripts for one time data modifications should NOT be stored in svn. Scripts should be added to the server manually and removed after they have been run.

8. COMPLETION

8.1 Once the migration process is completed, update.php will be run on staging to make any additional database updates.

8.2 Testing begins immediately after the deployment. If testing fails, immediately back out of changes and revert the database.

Moving from Staging to Production

Deployments to live are handled identically to checkouts to staging.
It is important to understand code and files never moves DOWN from dev to staging. There may be times we want to move user generated content from live to staging. This process does not address this issue.

1. SVN CHECKIN
1.1 Code gets checked into svn for deployment on staging. 1.2 All code updates must be stored in SVN in order to make their way to staging.
Obvious, but this should be explicit.

2. CODE
2.1 Code gets checked out on staging via svn. 2.2 The only code that gets checked out is referenced by a specific ticket. Any
other modifications are left in svn.

3. CONTENT TYPES
3.1 Content type changes are exported from dev to staging via the Content Copy module.
3.2 The content type definitions are copied manually by a user from dev to staging.

3.3 Content copy will modify any existing content types to add fields. Data
translation may be required.

4. VIEWS
4.1 Views are exported from dev to staging manually using views export. 4.2 Existing views with the same name are deleted from staging. 4.3 Views being imported are pasted into the import form and are now live on
staging.

5. DRUPALSETTINGS
5.1 Any modifications to settings in Drupal are made at this point.

6. FILE SETTINGS
6.1 Any modifications to files - such as paths in civicrm.settings.php - are made at this stage.

7. OTHER SETTINGS
7.1 Any mass modifications to data should be contained in a script.

7.2 Scripts for one time data modifications should NOT be stored in svn. Scripts
should be added to the server manually and removed after they have been run.

8. COMPLETION
8.1 Once the migration process is completed, update.php will be run on staging to make any additional database updates.

Database Mirroring

Deployments to live are handled identically to checkouts to staging.

1. SVN CHECKIN
1.1 Code gets checked into svn for deployment on staging.

1.2 All code updates must be stored in SVN in order to make their way to staging. Obvious, but this should be explicit.

2. CODE
2.1 Code gets checked out on staging via svn.

2.2 The only code that gets checked out is referenced by a specific ticket. Any other modifications are left in svn.

3. CONTENT TYPES
3.1 Content type changes are exported from dev to staging via the Content Copy module.
3.2 The content type definitions are copied manually by a user from dev to staging.

3.3 Content copy will modify any existing content types to add fields. Data translation may be required.

4. VIEWS
4.1 Views are exported from dev to staging manually using views export.

4.2 Existing views with the same name are deleted from staging.

4.3 Views being imported are pasted into the import form and are now live on staging.

5. DRUPALSETTINGS
5.1 Any modifications to settings in Drupal are made at this point.

6. FILE SETTINGS
6.1 Any modifications to files - such as paths in civicrm.settings.php - are made at this stage.

7. OTHER SETTINGS
7.1 Any mass modifications to data should be contained in a script.

7.2 Scripts for one time data modifications should NOT be stored in svn. Scripts should be added to the server manually and removed after they have been run.

8. COMPLETION
8.1 Once the migration process is completed, update.php will be run on staging to make any additional database updates.

Questions, Comments & Suggested Revisions

• leave em here!