- What kinds of outcome can I expect after signing up for Drop Guard?
- What do automatic updates mean, will you just push updates to my server without me knowing about it?
- How is Drop Guard different from similar tools?
- Can I use my favorite CI or testing tool with Drop Guard?
- Is there a hosted version of Drop Guard available?
- What level of expertise is required to use Drop Guard?
- Is Drop Guard intended to replace my current workflows?
- My website is heavily patched, will Drop Guard work for me?
- Do you provide any testing capabilities?
- Can Drop Guard be used as a deployment tool?
- Why should I install the Drop Guard module on my website?
- How secure is Drop Guard itself?
- How much time is needed to integrate Drop Guard into my current workflow?
- Can Drop Guard work with Acquia Cloud and Pantheon?
- What Drupal versions Drop Guard supports?
- Can Drop Guard work in an “auto-pilot” mode without human intervention?
- Can Drop Guard break my site? Who will be responsible for it?
- Do you provide a trial period or a free website to try Drop Guard?
- Do you support any project management system?
- Does Drop Guard support Composer- or Drush makefiles- managed websites?
- Does Drop Guard support projects checked out from Git? Added as Git submodules?
- Does Drop Guard support dev versions of modules?
- Does Drop Guard provide an API?
- Does Drop Guard update Drupal core?
- Is database access required to connect Drop Guard to my site?>
- Where are your servers located?>
We can name just a few:
- Ensuring continuous security of the contributed modules, libraries, and Drupal core;
- Performing updates in a highly controlled environment aligned with your QA process;
- Spending less time for websites maintenance, thus reducing costs and improving the efficiency of your business.
Drop Guard works in alignment with your Git-based workflow, which means that no updates or modifications will be ever pushed directly to your server without control about what happens. Drop Guard performs actions against the local copy of the Git repository and only affects the branches, (or spins up new branches) as per project configuration.
You can, for example, (and it’s in fact considered a good practice) configure Drop Guard to apply highly critical or critical security updates automatically right after they’re released, but again - all the updates will be pushed to the appropriate branches and it’s your call on how and when to deploy them. Integrated with your CI system, Drop Guard can let you test the updates on a separate instance, run automated tests or let you test manually and deploy to live only after you approval.
While we have a hard time trying to locate direct competitors, we think our competition can be split into two categories:
1. Update Monitoring
The infamous Update Manager module, which is included in each Drupal installation is the perfect example here.
Unlike Update Manager and similar online services, Drop Guard not only detects the available updates but allows to group them into categories by their importance (so called “update types” or “update criticalities”). It allows for fine-grained control over possible actions available when the update of a certain type is detected.
For example, you may want to notify your developer in case the normal update for a module is released, but in the case of a highly critical update the lead developer gets the “urgent type” email and a @channel message in Slack should be created.
2. Applying and Deploying Updates
Drop Guard is not just about monitoring; it’s about taking action in the safest way possible and in a controlled environment.
Services that try to do something similar usually fail simply because:
They don’t know Drupal as well as Drop Guard and the team behind it.
They try to push codebase modifications directly via SSH/FTP, which is somewhat dangerous even if you make backups
Drop Guard combines the best of two worlds, and how it is used, is your choice!
Writing tests in Behat or PhpUnit, running them with TravisCI and deploying with Jenkins, at the same time calling your coffee machine via the API to prep the perfect espresso when the build passes? We’ve got you covered!
Drop Guard’s architecture was initially designed to be extensible by any number of external tools a developer might use in their workflow, no matter how complex it is.
When certain events occur, you can send the HTTP request to the CI server, or execute SSH commands on your server - the possibilities are limitless.
Just an example - let Drop Guard create a feature branch for a module update, spin up a feature branch instance out of that branch, run automated tests, notify your QA. When the QA is satisfied with the results, let Drop Guard merge a feature branch back, run tests again, and trigger a deployment to the dev server.
Sounds complicated? How about letting Drop Guard apply the highly critical security update to your master branch immediately after it’s released, triggering the deployment to the live server, generating the invoice and emailing it to the happy client?
If you are running behind a private VPN, firewall or on the local network, please contact us via email@example.com for a solution.
To enjoy the full potential of Drop Guard you should at least:
- Have a basic knowledge of Git and have your code committed to a Git repository;
- Have a way to deploy (pull) the code from the Git repository to your production server. It can be the full blown CI system, or a simple bash script doing “git pull”. You can also configure Drop Guard to login to your server and run the deployment commands locally, so no extra tools or scripts are needed.
Absolutely not! Instead of trying to replace the existing workflows and habits, Drop Guard integrates into your processes with minimal changes required from your side. Once configured properly, Drop Guard runs silently in the background, notifying you and your tools when certain events are worth paying attention to. Very soon you won’t be imagining your life without Drop Guard!
Sure! When Drop Guard detects a code modification in one of the modules or Drupal core, it makes a patch out of it, does the update job, and tries to reapply the previously generated patch on top. With this mechanism, no code modifications will get lost after updates have been processed.
In the case of success, the update is considered as “passed” and you will get a nice overview on what was patched and a full auto generated patch output.
In case the patch fails to apply, the update process stops, and you get a notification about the error.
Pro tip: This way Drop Guard can be used to detect malicious code inserts, debugging code left by a careless developer, or accidental code modifications.
At the moment Drop Guard doesn’t do any testing by itself - it’s up to you which testing system or approach should be used. However, we are considering native integration with external testing services. If you are interested or have a tool to suggest - please contact us via firstname.lastname@example.org
By default, Drop Guard is not implied to be a deployment tool. There are plenty alternatives to choose from, both paid and free, complex and simple.
However, you can configure Drop Guard to run the deployment scripts on your live server, or even login via SSH and execute any number of commands locally needed to deploy the code.
We provide limited support for such actions and recommend using proper deployment solutions instead.
The client module is a requirement at the moment. It helps us with fetching the information on enabled modules and themes and their versions. The footprint is really low, the module was battle tested and used on hundreds of websites already.
However, we are working on a solution to make the client module optional. If you choose not to install the module, Drop Guard will fetch and apply updates for all projects in the repository, regardless of their enabled/disabled/uninstalled status. If you want Drop Guard to act on only enabled projects, the client module will be needed for that.
Follow our blog for updates!
Drop Guard is as secure as your server, and Drupal installation are. It acts on the copy of the Git repository without requiring server access. The client module transfers data on enabled projects over an encrypted connection, and we use 4096 bits keys to connect to your Git repository.
In fact, using Drop Guard is more secure than having the Update Manager enabled. Though we are not speaking of using Update Manager for fetching update archives. We have published a blog post on this case.
Depending on your experience and knowledge, it can be as low as 30 minutes of your time to learn the basic concepts and run your first project with Drop Guard.
For more complex workflows, a bit of clicking around and experiments is required, so the time may span to a few hours.
Always remember, though - the time spent on learning and configuring Drop Guard will allow you to save countless hours in future. It’s a good investment!
Besides, we are always happy to assist you in setting up your first projects in a hands-off session with Drop Guard expert. Just leave a note at email@example.com
Sure! You can use Acquia Cloud, Pantheon, Platform.sh or any other hosting provider with Drop Guard. If you think your provider is not supported or having trouble with setting Drop Guard on it, contact us immediately, and we’ll investigate the case.
Drop Guard provides full support for Drupal 7 and Drupal 8. Earlier versions can not be used with Drop Guard, as they are not officially supported anymore.
If by “auto-pilot” you mean automatically detecting updates, applying them to your Git repository and deploying to the live server right away - then the answer is a proud “Yes”.
However, we are not encouraging this practice, as you may soon face the case of incompatible module versions, buggy and untested releases and so on. Drupal is known for it’s distributed ecosystem, but it also requires us to be fully responsible for any 3rd-party code we use.
We recommend immediate updates only for releases with the “Highly critical” security update status.
Drop Guards acts on the copy of the Git repository and doesn’t require access to the live server, so there is no chance it will break the website.
However, due to the Drop Guard’s flexible configuration possibilities, it is very much possible to configure it to execute the harmful commands.
Drop Guard is not a magic bullet and an answer to all possible problems. In the end, it’s just a tool to assist a developer in his daily routine. All the actions and commands entered into the project configuration are the responsibility of a person who configures a project.
We always recommend to test SSH commands and deployment hooks before saving the configuration and work with development and feature branches avoiding pushing things directly to the production branches.
First of all, Drop Guard can be used for monitoring of any number of websites completely free of charge. We won't even ask your payment details. Just connect Drop Guard to your Git repository and the website and enjoy the robust notification system, 3rd party tools integration and other integration capabilities. You can even create tasks in your project management system when the new update arrives!
However, if you decide to let Drop Guard to take care of the updates for you, you can try it for 1 month for free. If you need more time - just let us know.
At the moment we support Jira only. Redmine and Erpal integrations will follow. If you want your project management system to be added, just send us a note
At the moment Drop Guard supports Composer-managed websites. An official Drupal.org repository and the Drupal Composer Packagist are supported. Instead of updating the actual Drupal codebase in your Git repository, Drop Guard makes changes to the composer.json file, filling it with proper modules and core versions as per Update behaviour configuration, then runs "composer update" command and pushes the changed files to your Git repository. It is a responsibility of a user to configure the appropriate Drop Guard actions for running deployment commands in the local shell or use a CI.
The Drush makefiles support is planned for the next months.
Drop Guard provides support for git submodules and projects checked out from drupal.org git repository. In the latter case, you will need Git deploy module installed for the Update Manager to fetch currently installed project information.
Yes. In the event of dev version detection, Drop Guard will compare project's datestamp with the datestamp of the latest "recommended" release, and if your version is older than the recommended one, an update will be offered. Otherwise, no update task will be created, and you are free to stay on the dev version for as long as you wish.
However, if the newer "recommended" release appears, and you still want to remain on the dev branch, it is mandatory to exclude the module from updates, or just ignore the update task created for it.
The API is still work in progress, and we hope to provide it for our users in the next months. In the meantime, we're collecting possible use cases to provide the best developer experience.
How would you use the Drop Guard API? Let us know in comments for this page or at firstname.lastname@example.org
Absolutely. Drop Guard takes care of the Drupal core and contributed modules updates.
No. Drop Guard never asks you to provide the database access details, because the only thing it deals with is the codebase managed by Git.
The underlying infrastructure is located in Germany. As the number of users across continents grows, we'll be adding extra servers in US and other regions.