README.md 4.39 KB
Newer Older
1 2
#Development workflow

3
All new code, etc. should be developed locally, commited to this repository, tested on www-test.civicrm.org, and the deployed on production. www-test should NOT be used for code based development.
4

5 6 7
It is good practice to use www-test to experiment with anything that does not happen at the code level (like configuration changes, creating views, permissions changes, etc.) but if you are making trivial changes, just adding content, etc., and you are confident of the results, please feel free to make the changes directly on the live site.

Note that many people have access to www-test, and it gets over written with data from www-prod on a regular basis, e.g. when testing upgrades of CiviCRM.  Therefore, you should let people on the infra list know about any changes you are making on www-test so they don't overwrite them, and NOT assume that your config changes will be on www-test next time you look.  Backup/Export any complex views, etc. to ensure they are there next time you look.
colemanw's avatar
colemanw committed
8 9

**Note:** Access www-test.civicrm.org with http username/password civicrm/civicrm.
10

11 12
## Development branches

totten's avatar
totten committed
13
www-prod should track the master branch.  Developments should happen on seperate branches and be merged to master when ready to deploy.
14

15 16
## Custom modules

17
All custom modules should be added to the sites/all/modules/custom directory and follow the naming convention civicrm_org_module_name.
18

totten's avatar
totten committed
19
## Releases
20

totten's avatar
totten committed
21
http://civicrm.org is served from www-prod.  All source-code is owned by the co user.  To do a release, use the latest code from the master branch to create a tag and then check out the tag on www-prod, e.g.
22

totten's avatar
totten committed
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
```bash
localhost$ ssh www-test
me@www-test$ sudo -u co -H bash
co@www-test$ cd /var/www/civicrm-website-org/
co@www-test$ git checkout master
co@www-test$ git pull
co@www-test$ ./tag.sh origin
## Make a mental note of the tag name (e.g. "deploy-2014-10-15-22-42")
localhost$ ssh www-prod
me@www-prod$ sudo -u co -H bash
co@www-prod$ cd /var/www/civicrm-website-org/
co@www-prod$ git fetch origin
## Checkout the appropriate tag, e.g.
co@www-prod$ git checkout deploy-2014-10-15-22-42
```
38

totten's avatar
totten committed
39 40 41
This process gives a clear trail of the timeline for code that has been deployed on www-prod -- which can assist in future debugging/auditing.

# Syncing to test and local environments
42

43 44 45 46 47
Syncing to www-test and local development environments is done in the standard way (mysqldump and restore the databases and rsync/copy the files).  You can then do a git pull (and so on) to check out appropriate code.

There is a script /home/michael/sync_co.sh on www-test that does this.  It needs to be run as michael at the moment, but we could generalising it should be trivial.

You should not need to worry about backing up the www-test database because no important data should be stored there (see development workflow above).
48

totten's avatar
totten committed
49
# Local development environments
50 51 52 53 54

You can develop locally as long as you are not storing any unencrypted personal data in your local development environment.

Drupal and CiviCRM databases can be encrypted on www-test.civicrm.org before being transferred to local development environments.

Michael McAndrew's avatar
Michael McAndrew committed
55 56 57 58 59 60 61 62 63 64 65 66 67
The site is hosted with nginx and this repository also contains some nginx rewrites that you can include with something like the below:


```
server {

    # Standard Drupal and CiviCRM nginx configuration here
    
    include /var/www/civicrm-website-org/config/rewrites.conf; # <-- add this line

}
```

totten's avatar
totten committed
68
# Upgrades
69

70 71 72 73 74 75 76 77 78
Upgrades (especially CiviCRM upgrades) should be

1) tested on a local copy first, then commited to the repo, then
2) tested on www-test

If all went smoothly in both instances, they can be carried out on the production server.

Notes:
* The drush command 'drush updb' is useful for just applying db upgrades when the code upgrade has already been done with a git pull (as is the case on www-test and www-prod).
79
* The drush command 'civicrm-upgrade-db' is useful for upgrading CiviCRM from the command line
80 81 82

Needless to say, if you do notice anything going wrong 
and on the test infrastructure before being carried out on the production server.
83

84 85
Put the site into maintanence mode before upgrading

totten's avatar
totten committed
86
# CiviCRM customisations
87 88

Any CiviCRM customisations should be places in the php and templates directory rather than being directly overwritted in order to make it easy to keep track of customisations through upgrades.
Michael McAndrew's avatar
Michael McAndrew committed
89 90 91 92

# Support

Please email michael@civicrm.org or totten@civicrm.org if you need any support with any of the above.