Fundraising/techops/docs/fundraising cluster deploy

Fundraising Cluster Deploy

Once your code is merged in gerrit, and any localsettings configuration is pushed to the shared repository, follow the steps below to deploy to fundraising servers.

1. Shut down the thing you are updating, if this is a substantial change.
2. Log in to the active fundraising deploy server

   ssh frpm1002

3. Run fundraising_code_update to refresh the deploy server's staging area
   Generally you'll want to update one project at a time as in this example, although other options are possible.

   fundraising_code_update -p civicrm

4. Confirm the reported commit changes match what you expect, you can inspect the contents of the project staging directory which is listed by

   fundraising_code_update -i

5. Run rsync_blaster to propagate this staged code to the individual servers
   This example deploys to all servers where the civicrm project is installed, but it is also possible to sync specific servers i.e. for a canary deploy.

   rsync_blaster ALL:civicrm

6. Log action into #wikimedia-fundraising by typing the below (where xyz & abc are the commits) into IRC

   !log Updating civicrm from xyz to abc

7. Turn your stuff back on and make sure it works.

fundraising_code_update

fundraising_code_update is a CLI tool run on the fundraising deployment server, which preps the local staging area for one or more project. It fetches the desired version of the software from version control (gerrit) including submodules, tweaks file attributes, overlays configuration files from the private localsettings repository, and keeps track of current and previous revision IDs to make it easy to roll back to the previous release. The staging area is owned by the configured deploy user and writable only by that user.

See -h help for more information on how fundraising_code_update can be used.

rsync_blaster

rsync_blaster is a CLI tool run on the fundraising deployment server which uses rsync to deploy whatever is in the staging area to the target hosts. It will optionally run a remote 'service-restart' command after the rsync. It allows fine-grained control over deployment allowing you to do canary- or other phased deploys. Deployment status reports are available at a cluster (-s) or target (-t <host>) level, showing the time and commits IDs last deployed.

See the -h help page for usage examples.