kostajh/security-updates-best-practices

## security-updates-best-practices
Security Updates Best Practices
==================================

The general workflow for running security updates is:

1. Make sure your local development environment for the site is up-to-date (sync the database from production, if needed)
   1. If the site hasn't been managed for a long time, use `drush rsync @example.prod @example.local` (using the `--exclude` flag to exclude large directories like `sites/default/files`). Then type `git status`. If there are any unmanaged files, add them to version control.
2. In your local environment, run `drush up --security-only`.
   1. Look at the list of packages that will be updated. Go to each project page on Drupal.org and read the release notes.
   2. You may need to read several versions worth of release notes. You want to see if there are mentions of breaking changes or any changes to features/functionality your site uses. This is usually the most time consuming and difficult part of running the updates.
   3. Now, allow Drush to run the updates.
   4. After the updates finish, do `git checkout .htaccess` to restore your custom `.htaccess` file. (N.B. on rare occasions, updates to Drupal core involve changes to the `.htaccess` file so make sure you incorporate those changes if needed)
   5. Visit your local site and click around, both as an anonymous and authenticated user, to ensure the site functions. Most serious problems with core / contrib updates can be caught this way, although it's not substitute for a full test suite.
   6. Visit `admin/reports/status` to check for any errors there.
   7. After clicking around, check the watchdog entries to see if anything unusual shows up.
3. The updates have now been run locally, and Drupal core and contrib modules are up to date. Now we need to commit our changes.
   1. Commit the updates one project at a time, rather than in one big commit that includes all core/contrib updates.
   2. Push your changes up to origin.
4. SSH into the staging environment, if it exists. Run `git pull` to bring over the latest changes, then `drush updb` to run database update hooks
5. SSH into the production environment. Run `drush sql-dump --result-file={some_destination} --gzip`, to backup the production database. After running the command, run `du -h` on the generated file to ensure it's a reasonably sized file and that `sql-dump` did not fail.
   1. Run `git pull` and `drush updb` in production.
   2. Click around the site as an authenticated and anonymous user. Check the watchdog entries. If everything looks good, you're done!
   3. If there is a problem, set site to maintenance mode, use `git reset [previous-commit] --hard`, import backup you just took, and remove maintenance mode to fully return it to previous state.
	Security Updates Best Practices
	==================================

	The general workflow for running security updates is:

	1. Make sure your local development environment for the site is up-to-date (sync the database from production, if needed)
	1. If the site hasn't been managed for a long time, use `drush rsync @example.prod @example.local` (using the `--exclude` flag to exclude large directories like `sites/default/files`). Then type `git status`. If there are any unmanaged files, add them to version control.
	2. In your local environment, run `drush up --security-only`.
	1. Look at the list of packages that will be updated. Go to each project page on Drupal.org and read the release notes.
	2. You may need to read several versions worth of release notes. You want to see if there are mentions of breaking changes or any changes to features/functionality your site uses. This is usually the most time consuming and difficult part of running the updates.
	3. Now, allow Drush to run the updates.
	4. After the updates finish, do `git checkout .htaccess` to restore your custom `.htaccess` file. (N.B. on rare occasions, updates to Drupal core involve changes to the `.htaccess` file so make sure you incorporate those changes if needed)
	5. Visit your local site and click around, both as an anonymous and authenticated user, to ensure the site functions. Most serious problems with core / contrib updates can be caught this way, although it's not substitute for a full test suite.
	6. Visit `admin/reports/status` to check for any errors there.
	7. After clicking around, check the watchdog entries to see if anything unusual shows up.
	3. The updates have now been run locally, and Drupal core and contrib modules are up to date. Now we need to commit our changes.
	1. Commit the updates one project at a time, rather than in one big commit that includes all core/contrib updates.
	2. Push your changes up to origin.
	4. SSH into the staging environment, if it exists. Run `git pull` to bring over the latest changes, then `drush updb` to run database update hooks
	5. SSH into the production environment. Run `drush sql-dump --result-file={some_destination} --gzip`, to backup the production database. After running the command, run `du -h` on the generated file to ensure it's a reasonably sized file and that `sql-dump` did not fail.
	1. Run `git pull` and `drush updb` in production.
	2. Click around the site as an authenticated and anonymous user. Check the watchdog entries. If everything looks good, you're done!
	3. If there is a problem, set site to maintenance mode, use `git reset [previous-commit] --hard`, import backup you just took, and remove maintenance mode to fully return it to previous state.