diff --git a/README.md b/README.md index 81f3177..1620bc2 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,7 @@ My Personal notes and bookmarks regarding Work, Drupal, Project management and m - [Migration from 8.x to latest version](drupal/migration-8-plus.md) - [README template](drupal/readme-template.md) - [Script: Get Prod config](drupal/script-get-prod-config.md) + - [Security Updates for Drupal](drupal/security-updates.md) - [Selling Drupal](drupal/selling-drupal) - [Start with Drupal](drupal/start-drupal.md) - [Teamocil (tool)](drupal/teamocil.md) diff --git a/drupal/README.md b/drupal/README.md index 443fdc9..aff562c 100644 --- a/drupal/README.md +++ b/drupal/README.md @@ -19,6 +19,7 @@ - [README template](readme-template.md) - [Script: Get Prod config](script-get-prod-config.md) - [Selling Drupal](selling-drupal.md) +- [Security Updates for Drupal](security-updates.md) - [Start with Drupal](start-drupal.md) - [Teamocil (tool)](teamocil.md) - [Terminology](terminology.md) diff --git a/drupal/mastering-authoring.md b/drupal/mastering-authoring.md index d8262f5..4aecfd8 100644 --- a/drupal/mastering-authoring.md +++ b/drupal/mastering-authoring.md @@ -23,7 +23,7 @@ ## Other - UI option to take backups before any change -- DEV/STAGE/PROD environemnts +- DEV/STAGE/PROD environments - Override backend theme - Custom Admin content views - All blocks on code (under vcs) diff --git a/drupal/security-updates.md b/drupal/security-updates.md new file mode 100644 index 0000000..1c6228e --- /dev/null +++ b/drupal/security-updates.md @@ -0,0 +1,72 @@ +# Drupal security updates + +> Drupal security updates guide and best practices. + +## Important things to know + +- Drupal core and contrib modules security updates are maintained by the [Drupal security team](https://www.drupal.org/drupal-security-team). +- **Security release "windows" are every Wednesday for Drupal contributed projects, and one Wednesday a month (usually the third Wednesday) for Drupal core.** See more at [D.O.: Security release numbers and release timing](https://www.drupal.org/drupal-security-team/security-release-numbers-and-release-timing) +- For Drupal core the **bug fix/feature** rele1ase window is on the **first Wednesday of the month**. +- Security releases happen between 16:00 UTC and 22:00 UTC. +- D.O. Security updates list: +- D.O. Security updates Twitter alerts: + +## When to do the updates + +- Always use a maintenance window and a **shared calendar** (with the customer) to plan the updates. For example. you should not do the updates (even if there is a sec. issue) when the site is having a high traffic campaign. +- Prefer the same dates as Drupal core security releases. For example, **the third Wednesday of each month** is a good option to plan for updates. +- ASAP when the security issue is of high priority. +- Do not do the updates late on the day (at least 4 hours before leaving the office) or on the last day of the week (eg Friday). +- Try to do the updates when all the related parts are active (developers, sysadmin, hosting provider, customer etc) +- Do not plan for updates then other systems (eg the Hosting Provider) is also having a maintenance window. + +## Best practices + +- Security updates should be done as a "**first level task**" and not as a minor boring task. +- During the update the developer(s) should always follow all the steps even if you are sure they are not needed. +- During the update the developer(s) should not be tired, doing multitasking, talking on the phone etc. +- During the update the developer(s) should not be on a hurry when doing the sec. updates. +- After the update the developer(s) should monitor the site for some time and be ready to revert/act if anything happens. +- Demand a **content freeze** during the updates (you can use the module [readonlymode](https://www.drupal.org/project/readonlymode) or the core **maintenance_mode** variable for that). +- Maintenance windows (date or range of dates). +- Maintenance calendar (a shared calendar where the site owner should mention which dates should not be an option for security updates). +- Maintenance emails (inform the customer about the **upcoming** update, inform the customer about the update **happened**). +- Create a technical report about each update (git tag/commit, Drupal core, Drupal contrib versions, PHP packages versions). You can use tools like [generate_drupal_report](https://github.com/theodorosploumis/generate_drupal_report). +- Add **datetime to bash history** so each cli command has a datetime entry. +- Use a special **cli color when ssh on a Production server** (eg make it with red background). +- Allow for emergency **system rollback** from the UI (code, database, public files). This is needed in cases where an error occur after a sec. update and there is lack of communication between the sec. team and the site owner. +- First complete the sec. updates on a **full copy of the Prod site (code, db, public files, same server config)** before doing the same on Prod. +- Establish a **manual (UAT) testing** guide to allow the customer check the updates. +- Establish a **clean plan about the responsibilities**. Who is going to have each responsibility, which are the communication options (email, phone etc), which are the tasks need to be done when a problem arise etc. +- If there are **many companies or vendors evolving** be careful about any misunderstands and delays that may happen due to the number of the people evolved. + +--- + +## Monitor site health + +- Uptime monitoring (external SASS, eg [uptimerobot](https://uptimerobot.com), [New Relic](https://newrelic.com)) +- Get SMS and email alerts for PHP fatal errors on Drupal + +--- + +## UAT examples for Drupal + +- View a node (for each bundle) +- Edit a node (for each bundle) +- View a list (views) +- User login works +- Webform submissions work +- Search works +- Cron task works +- SMTP and mail system works +- There are no JS errors on console + +--- + +## Related guides + +- [Drupal report](https://github.com/theodorosploumis/drupal-report) +- [Generate drupal report script](https://github.com/theodorosploumis/generate_drupal_report) +- [Notes: Drupal Contract](contract.md) +- [Notes: Deployment workflow for Drupal](deployment-workflow.md) +- [Notes: Testing Drupal](testing/README.md) diff --git a/drupal/testing/README.md b/drupal/testing/README.md index 960df6c..98eaee1 100644 --- a/drupal/testing/README.md +++ b/drupal/testing/README.md @@ -37,10 +37,11 @@ ## Examples -What to test with a Drupal project: +What to test for a Drupal project: - dev\* and \*\_ui modules are disabled on Production -- A user for Role X can submit a node form +- A user of Role X can submit a node form of a bundle +- A user of Role X can view a node of a bundle - New site can be installed from configuration and/or demo content - REST API (CRUD operations) - REST API (get Nodes single, list, filtering, pager) @@ -52,7 +53,7 @@ What to test with a Drupal project: - REST API (security test) - REST API (Permissions) - Functionality (eg module API, test functions) -- Permissions (eg a Druapl user can access a page) +- Permissions (eg a Drupal user can access a page) - Integration (eg PHP versions, dependencies versions, Drupal core versions) - UI (Expected behavior on a Drupal page) - Code validation according to standards