After you’ve decided how Drop Guard should interact with available update types in general on the previous page, you will now configure what exactly needs to happen in this pipeline and you will give Drop Guard the instructions for your individual process.

Definition of “Events”

An Event is one stage of your update pipeline. It starts with the stage that an update is available and covers the interaction with stages like failed patches or passed tests etc. When an update is processed - f.e. when Drop Guard pushes the updated version of a module to your git repository, or the QA team sets the update task status to “Test passed”, or the patch fails - you can tell Drop Guard what to do in such cases by adding specific Actions to every single Event.

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:

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).

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).

  • 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.
  • 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.
  • 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.

    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).

  • 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.
  • 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.
  • Task status is “Failed”: if some action failed due to missing accesses f.e., let yourself be informed by Drop Guard!
  • A patch could not be applied: get informed if a task failed because Drop Guard couldn’t re-apply a custom patch.
  • 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”.

Important hacks

1. Execute certain Actions only once per group of tasks

In case you execute more than one update task in one run, you can tell Drop Guard to execute the action attached to a specific Event only once to avoid running this actions as many times as the number of tasks in a batch (f.e. Merge of a branch, or a testing process).

To achieve this behavior, simply check the box within the “Request a URL” (see screenshot below). The action will be executed within 5-10 minutes after the update task status changed.

2. Bulk merge of tasks

If you add the action “Merge a branch” please decide whether Drop Guard decide if you want Drop Guard to wait with the merge action until ALL tasks of your test branch are set on “test passed” or “closed” (as it is pre-configured as default) or if it should merge a branch already when only ONE task is set on “test passed” (if so, please uncheck the box).

How to handle Events & configure Actions in Drop Guard - Demo Video

A new demo video of the Events configuration will be uploaded soon. If you need help with the setup, contact us via support@drop-guard.net or join our Slack channel.

Congratulations, you just set up your project completely!

After this deep configuration, you can add a subscription to this project and unpause it to let Drop Guard do the work for you.