Big update: the new onboarding process, improved patching workflow and more
Today, we’re excited to introduce you to a number of new features, improvements and fixes for Drop Guard - the first major update in the series of releases planned for 2016. It includes many enhancements designed to improve user experience when creating projects in Drop Guard, support for the "Unsupported updates", and even smarter automated patching workflow. Read below to learn about the major improvements and don't forget to check your Drop Guard account to see it by yourself. Let's dive right in!
The new onboarding process
Existing users are well aware of the legacy project creation form - it required you to enter not only the Git and website connection details but also configure the Update behaviours and Events handling all at once. For newcomers and those who're not familiar with Drop Guard concepts it might get confusing a bit.
To make the project creation process as painless as possible and to allow users to evaluate Drop Guard's potential without having to invest much time in it, we've decoupled the configuration process into three independent screens.
1. To be able to create a project and use Drop Guard in the monitoring mode (without it doing any changes or modifications to your Git repository), all you need now is to provide the Git and website connection details, and (optionally) configure basic email notifications.
Drop Guard will immediately start monitoring for updates in 24/7 mode, but no update tasks will be created.
2. When you're ready, jump into the "Update behaviours" configuration screen and enjoy our new wizard, which is now the default for the Update behaviours handling.
Its primary purpose is to guide a user through all available Update types one by one, at the same time allowing to group them quickly together for a less granular configuration.
If you're uncertain about the best setting for a given update type, just click on the "Next" button and it will pick up the recommended options for it and even more - group similar update types together.
Update behaviours configuration for a project can take as less as one minute of your time - we've tried this!
For die-hard Drop Guard users, the old form is available as the "Expert mode" now - feel free to choose any approach you like most.
3. Lastly, there is the "Events" configuration form.
It hasn't changed much, but there are a few things to note:
- When creating a project for the first time and configuring basic email notifications on the "Add a project" form, the "Events" form will be pre-filled with the appropriate "Send email" actions;
- As this form is decoupled from the project creation form now, don't forget to check on it, as it's the only place where you can configure branches merging, deployments and 3rd-party systems integration;
- When setting up actions, you won't find two update types that were there before. More on that right now.
Less update types to configure
As you've probably noticed on the screenshot above, two update types are gone now and no longer available - those are the "Default" and "Security updates - All".
If you want to have the same update behaviour for all or a group of update types, use the new configuration wizard or just apply the same settings for the update types in question.
Support for the "Unsupported updates"
In rare cases, Drop Guard detected module upgrade paths which are not supported by the project maintainer. In the Update manager they are usually visible as "Unsupported updates".
As no one can guarantee that such an update will be applied cleanly and it most likely means there is no backwards compatibility for a new version of the module, Drop Guard refused to create update tasks for such updates, providing little information to a user.
For users who want to be in full control over all possible situations, we've added a new update type, which is visible only in the Expert mode and is disabled by default, where they can configure the update behaviour for the Unsupported updates.
Drop Guard will not group such updates, and will not commit them automatically, but depending on your configuration a separate task for each update will be created and it can be executed as any other.
Simplified patches detection system
As it was a rather time-consuming process, we've disabled an option to add manual patches on the module configuration screen. There is also no way of checking for modifications manually.
Here is how it works now.
1. Drop Guard checks for patched (modified) modules, themes and core when executing an update task.
2. If a modification is found, Drop Guard makes a diff and a patch out of it.
3. Next, it checks the user configuration for the update type the task belongs to. There are two options here - to stop the update process if a patch can not be reapplied, OR to continue update process ignoring the merge conflict in the problematic file.
4. Drop Guard performs an update, tries to apply the auto-generated patch and follows the setting configured by a user to decide what to do next - to stop or continue the process.
This way users have to set the patching behaviour only once for each update type without having to bother about each module individually.
And, as with any Drop Guard release, we've included many bug fixes, minor UI enhancements, an improved handling of dev versions of modules and many others.
As usual, the best way to learn about all the major and minor improvements and fixes is to visit your project page in Drop Guard, check its settings, ensure everything is configured according to the best practices and is aligned with your workflow and obliviously - continue enjoying Drop Guard as the ultimate updates automation tool.
If you want to get a sneak peek on what's inside without creating an account or need some more guidance and help, enjoy our first video, covering the project creation process. In the next videos of this series, we'll be talking about Update behaviours and Events - stay tuned and subscribe to our channel on YouTube!