You’ve just created your first project in Drop Guard in the previous step. Within this process, you gave your project a name, you provided Drop Guard access to your git repository and selected whether your project is managed by composer or not (if you had problems at this state of project creation, contact us (link to DOCS contact page), we’ll help you to create your project successfully!).
So, now that you have the basis for a smooth - and automated update process - it’s time to dig deeper and add the crucial details: How should Drop Guard behave when an update is available?
After saving your project basic settings, you get forwarded to the project’s overview page and some notifications pop up at the top of this page:
- Congrats! You can now continue with adding Update behaviors and Events.
- Your project is paused: nothing will happen until you unpause your project, so feel safe to configure everything calmly. After the 14 days free trial, you will be requested to add a subscription plan: without a subscription plan, you are only able to set up a project for update monitoring purpose.
But first: add new update behaviors - this is what we are looking for right now as a next step.
Step 1: What process should be implemented?
Get a clear picture of how your current update process (if you have one) is running and agree with your team and/ or customer on how Drop Guard should adapt to this process. This could mean that you map it completely alike, or configure an optimized version or even totally different to test a new update process. It’s your own free choice!
Step 2: Set up update behaviors
Click on the provided link for “Update behaviors” in the notification popups or enter the configuration view (“Configure this project” on the right corner). You already configured the first two tabs within the project creation process. So let’s go to the “Update behaviors” tab directly.
Update behaviors tab overview
1. ADVANCED and SIMPLE mode
You can decide whether you want to configure all update types:
- Highly Critical (scores 20 to 25)
- Critical (risk level of 15 to 19)
- Moderately Critical (10 to 14)
- Less Critical (scores 5 to 9)
- Not Critical (risk level between 0 and 4)
- Normal (all non-security related module updates)
If you chose to use the “SIMPLE” mode, the “Security-related” update type merges 4 update types: Critical, Moderately Critical, Less Critical and Not Critical.
2. Behavior settings for each update type
Decide if you want Drop Guard to perform updates for each specific update type at all by checking or unchecking the “Apply updates to...” box right below each update type. If the box is unchecked, this update type will be excluded from updates.
By clicking on these Update types one after another, you can configure these 6 general behaviors for each type individually:
1. Apply updates: decide on which branch Drop Guard should deploy the update at the end (this field enables the specific update type to be respected within the process, so if you uncheck it, this update type will not be respected). Specify the Git branch you want the updates of this type to be committed to - Drop Guard will push all updates to this branch (but respect that if you enable the “feature branch” property - it’s the following checkbox, and it’s explained in detail below -, Drop Guard will push all commits to the feature branch instead). The list of your branches will be pulled into the select list and the most appropriate branch will be suggested automatically. This branch will be also used as the source for any feature branch created for updates of this type.
2. Create feature branches: you can let Drop Guard commit updates to a feature branch. It will be created from the branch specified in the “Apply updates..” checkbox above. If unchecked, all updates will be committed to the source branch you’ve set above. When you are using feature branches, don’t forget to create the “Merge branch” action on the “Events” screen of the project edit form, so your QA process is fulfilled. A good recipe is to merge the feature branch when the task status is “Test passed” or “Closed”.
3. Execute manual tests: if you (or your customers) want to test updates manually on a specific state, check this box. When it's checked, the tasks need to be set on "Test passed" by someone responsible for QA within the Drop Guard interface or triggered via project management tools such as JIRA or Redmine. If it’s unchecked, Drop Guard will apply the new update code and will set the task on “Test passed” if the new update could be applied without any issues.
4. Commit updates automatically: if Drop Guard should start with your configured process automatically, check this box. Otherwise, you have to kick-start every available update manually. This checkbox is essential for the “Highly critical” updates, as the website should be patched as soon as possible, otherwise you’re at risk to get hacked.
5. Stop process if a patch could not be applied: yes, update automation and patches can work out at the end! It’s Drop Guard’s goal to preserve the customized changes of your modules. Check this box if you want to re-check manually when Drop Guard couldn’t apply your custom patch due to a merge conflict. In Detail: While performing an update, Drop Guard checks the specific 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 re-apply the patch. Then it’s up to you to decide whether you want to stop the update process and review what went wrong or to proceed, discarding your modifications. We recommend having this one checked for all update types except “Highly critical”. You will find a log file in the Error task to understand what failed.
6. Create git tag: Drop Guard can add a tag to the updated commit when pushing it to your repository. You can also create Git tags for various events on the "Events" screen.
3. Please also configure how Drop Guard should handle its own updates in rare cases.
Drop Guard needs to update itself in rare cases as well. An updated module ensures the seamless functionality of the tool. Click here to learn more about the Drop Guard live site module. Drop Guard will handle its own module updates like other module updates of the update type you need to set in the next box:
And finally, there is the "Reload best practices" button at the bottom of the page 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.
This video below explains how to configure update behaviors properly.
YES! - you’ve just set up how Drop Guard should react to each type of update out there in the wild! Let’s get to the magic page, which needs some concentration.