How does Drop Guard know what to do? About Update behaviors & Events

How does Drop Guard know what to do? About Update behaviors & Events
A tool only performs as good as it’s configured and handled. This post gives detailed insights into the important touch points of the Drop Guard actions you need to configure in order to benefit from a smooth and individual update pipeline. 

Step 0: You've created your project

Let’s start with this scenario: You have successfully created your first project in Drop Guard via the “Projects” menu item. 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 (you had problems at this state of project creation? Contact us, 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 Drop Guard should behavior 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: 
  • Your project is paused: nothing will happen until you unpause  your project, so feel safe to configure everything calmly
  • Add a subscription plan: without a subscription plan, you are only able to set up a project for update monitoring purpose (you need to install the Drop Guard module on your live site for this) 
  • Add new update behaviors now: YES, this is what we are looking for right now as a next step. 

Step 1: What do you want?

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 (completely alike, optimized 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 at the top of your project’s overview page (in the correlating notification popup) or enter the configuration view (“Configure this project” on the right corner). 
We start with the “Update behaviors” tab

Update behaviors tab overview

1. ADVANCED and SIMPLE mode

ADVANCED
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)
SIMPLE
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. 
Learn more about Security risk levels on drupal.org

 

2. Behavior settings for each update type

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. The list of your branches will be pulled into the select list and the most appropriate branch will be suggested automatically.
  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, Drop Guard won’t close the update task until the "Test passed" button will be clicked by someone responsible for QA within the Drop Guard interface or triggered via project management tools such as JIRA or Redmine.
  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. 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 update commit when pushing it to your repository.

 

3. Please also configure how Drop Guard should handle its own updates in rare cases.

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.

 

Excuse me, I just don’t get it - you can contact us, join our Slack or start again with the “Reload best practices” button at the end of the Update behaviors tab (step 4 in the screenshot above). 

 

Step 3: Actions, please! 

After you've decided how Drop Guard should interact with available update types in general, you will now configure what EXACTLY needs to happen in this pipeline and you will give Drop Guard the instructions for your individual process
These actions will be configured on the “Events” tab of the project configuration view. Between “Update behaviors” and “Events” tab, you can also integrate your Project Management/ Communication tools (JIRA, Redmine, Slack) and hosting providers (Pantheon, Acquia, soon: Platform.sh) if there are any included within your update process. 

Let’s start with an overview:

Events tab overview

 

1. Available actions

Check out the essence of this page: the available actions. This list is the detailed listing of all available actions that can be chosen in each update process below (blue fields). BUT: if you haven’t added a tool integration like JIRA, Slack or Redmine, you will not be able to choose the applicable action as it won’t be displayed (until you enable it on the “Integrations” tab). 

Available actions on Events tab

2. Re-check your Update behaviors

Click the button “Show your Update behaviors” to see a brief overview of the instructions you gave Drop Guard in the “Update behaviors” tab. Why do you need to be reminded of this for configuring the actions? Because if you configured that Drop Guard should apply a Highly Critical update to your master/ production branch f.e., you should now insert the specific link to this branch for all Highly Critical updates and not provide the link to another branch just because you forgot about your settings. Simply put, it’s a reminder for you so you don’t mess up your previous settings ;-) 

3. Configure actions 

We’re at the last step. Now you can call your desired update process into being by telling Drop Guard how to respond in certain update process situations (events). 
  1. New updates are available: Drop Guard already created an update task at this point. You can configure f.e. to be messaged by Drop Guard at this point via email or via a ticket.
  2. Task status is “Ready to test”: Drop Guard applied the new available update to your current module version of your git repository. So now either you/ your customer can test the website (check your Update behavior overview with the grey button above and ensure if you enabled manual tests), an external testing tool or Drop Guard tests automatically. 
  3. Tasks status is “Test passed”: a successful test - done manually, with tools or by Drop Guard - results in a “Test passed” marked task. At this point, all “Test passed” marked tasks can be merged to a branch. 
  4. ATTENTION: if you follow our best practices, you let Drop Guard merge available HIGHLY Critical updates directly without testing them (security beats functionality), which means that Drop Guard assumes that these tasks are in the “Test passed” status anyway, so you have to add the “Merge a branch” action to the production or master branch here for Highly Critical updates).
  5. Task status is “closed”: If a task got closed manually or via a project management tool, you can add an action to get informed about it. 
  6. Time schedule of actions: this action enables you to schedule each action - this means that you can control the day and time of the configured actions. 
  7. Task status is “Failed”: if some action failed due to missing accesses f.e., let yourself be informed by Drop Guard!
  8. A patch could not be applied: get informed if a task failed because Drop Guard couldn’t re-apply a custom patch.
  9. Task status “Test failed”: if a task status was set on “Failed” - f.e. Via JIRA after your customer tested the update on their website - you can configure what Drop Guard should do.
IMPORTANT: The Actions will be executed in the same order as you position them on the Events management screen. If any Action fails, all further Actions will not be executed and the update task status will be set to “Error”.
You’ll find the Drop Guard DOCS section about Events and actions here.

 

PHEW, we made it!! 
After this deep configuration, you can add a subscription to this project and unpause it to let Drop Guard do the work for you.
As an update process combines quite complex steps, we know the nice feeling of mapping the own, the optimized or requested process successfully.

 

If you need help to configure your individual process or if you don’t know how to align Drop Guard’s functions with your process, contact us, join our Slack or request a personal demo with our dev team.
We’re always happy to make you and your project successful.