Drop Guard recipes: Configure your Drupal update behaviours
Immediately after creating a project you will be able to monitor your website for updates, configure email notifications (i.e. being informed about security updates only or all types of updates across your projects), fire SSH commands and even integrate with 3-rd party tools.
However let's agree - this is not what Drop Guard is around. The real benefits and value of our service are not about being able to monitor, but actually perform updates by committing the newer Drupal and modules versions directly into the project's Git repository. In this article, we'll familiarise ourselves with the basic Drop Guard concepts, and go through the update behaviours configuration process to secure our website.
Create a project first
If you want to follow along, and don't have a Drop Guard project or the account yet, go ahead and create one, it's easy!
After the project is created it will be paused, which means that no updates or modifications will be made to your repository and it's safe to go ahead and configure update behaviours now. Follow the "Add update behaviour" link to proceed to the update behaviours configuration wizard.
A bit of terminology
Before jumping into it, let's talk about terminology a little (yes it sounds boring, but we promise to cover it real quick). In Drop Guard's parlance there are a couple of specific terms to get acquainted with.
Update behaviour - Drop Guard configuration for the specific "Update type". In simple words, by configuring the update behaviour we tell Drop Guard what to do in case an update of a particular kind is detected. Should it create a feature branch, figure out how to process failed patch, decide which branch to use for the update - those things are covered in the update behaviour configuration.
Update type - this is how we call the well-known "risk levels", although in a broader sense. Check the D.O. page on the risk levels for more details. You may wonder why we didn't use the "risk level" term - the answer is that there are a couple of update types in Drop Guard which are not related to security risks at all. For example, you may have "Normal" or "Unsupported" updates for your projects. Those, as well as security-related risk levels, are called the "Update types" in Drop Guard.
Task - the update job created by Drop Guard to process a single or a group of related updates, depending on the configuration. For performing actual updates Drop Guard creates update tasks which can be processed manually (by executing them from the interface), or automatically as soon as the update is detected.
Update behaviour configuration
Enlightened, we can take a fresh look at the update behaviours configuration wizard. It was designed to be friendly and fast, and it allows you to complete the configuration for all update types in just a few clicks!
First, we have to configure the update behaviour for the "Highly critical" updates; after clicking on the "Next" button you will be configuring the group of non-critical security updates, and lastly - the Normal updates (or non-security updates).
If you wish, you can group update types in a different way by clicking on the checkboxes at the top. This is handy if you want to have the same configuration for all update types for example - just select all update types, decide on the config, and you're done.
Let's see what settings can be applied for a single update type and how can we use them to achieve best possible results.
1. Decide if you want Drop Guard to perform updates for the specific update type by checking or unchecking the "Apply updates to..." box. If unchecked, this update type will be excluded from updates.
2. Specify the Git branch you want the updates of this type to be committed to. The list of branches will be pulled into the select list and the most appropriate branch will be guessed automatically.
3. Next, you will be dealing with a small set of checkboxes.
- Decide if you want Drop Guard to create a feature branch for this update. If unchecked, all updates will be committed to the source branch we've set above.
NB: When using feature branches, don't forget to to create the appropriate "Merge branch" action on the "Events" screen of the project edit form.
- If you're performing manual or automated tests for your updates, check the next box. When it's ON, Drop Guard will not be closing an update task until the "Test passed" button will be clicked by a user.
- Next checkbox is an important one - if checked, Drop Guard will push updates automatically right after they're detected. This is essential for the "Highly critical" updates, as the website should be patched as soon as possible, otherwise you're at risk to face the next Drupalgeddon effect eventually.
- The last checkbox is used for cases when the update could not be applied because of the merge conflict.
While performing an update, Drop Guard checks the module for modifications. If such is found, it makes a patch out of it, applies an update against the "clean" version of the project, and tries to reapply the patch. Then it's up to you to decide whether to stop the update process and review what went wrong or proceed, discarding your modifications, at the same time writing the output to the task log. We recommend having this one checked for all update types except "Highly critical".
4. And finally, there is the "Reload best practices" button which is a life saver in case you're unsure which settings to apply for the given update type, or just messed with configuration a bit and want to revert to the default state.
Note the "Switch to expert mode" link at the bottom - it allows you to switch to the old good traditional way of update types configuration, where all settings are listed on the same screen.
There is one hidden gem in the "Expert mode" - here you can configure the update behaviour for the "Unsupported updates". It was placed there for a reason - in most cases those updates should be processed manually as there is a high risk to break things when applying the updates which are not supported by the project maintainer and most likely they lack backwards compatibility with the previous versions.
Review, adjust and enjoy
After all update types are configured, review the configuration on the Summary screen, amend things if necessary and hit the "Save" button.
That's it! If the project is not on pause, Drop Guard will start processing your updates following the configuration we just did.
If you haven't done it already, it's a good time to visit the "Events" section of the project edit form and configure email notifications, deployments, 3rd-party tools integration and branches merging, if you decided to create feature branches for any of the update types.
Is anything still unclear or have questions to clarify? Drop us a line at firstname.lastname@example.org or ask in the comments. We're always looking for the feedback which helps us to improve the service. Stay tuned for updates!