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 "Configure update behaviours" link to proceed to the update behaviours configuration wizard.
First, we have to configure the update behaviour for the "Highly critical" updates; after clicking the "Next" button you will be configuring the group of non-critical security updates, and lastly - the Normal updates (or non-security updates).
Let's see what settings can be applied for a single update type and how can we use them to achieve the best results.
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.
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. This branch is also used as a source for any feature branch created for updates of this type.
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 create the "Merge branch" action on the "Events" screen of the project edit form. A good recipe is to merge the feature branch when the task status is "Test passed" or "Closed".
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 someone responsible for QA.
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.
This 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".
The following checkbox can be used to tell Drop Guard to create a Git tag for update commit. You can also create Git tags for various events on the "Events" screen.
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.
This video explains how to configure update behaviours properly.