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.
Update behaviour configuration (wizard mode)
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.
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.
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".
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.