Drop Guard recipes
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.
Update automation sounds nice as long as you don’t think about your (heavily) patched Drupal project, right?
In this “recipe” I will explain how Drop Guard handles custom patches within a fully or partly automated update process.
1. Update release
An update got released on Drupal.org. Only a few minutes later, Drop Guard detects the update release information, such as update type and version.
The real benefits and value of Drop Guard are not about being able to monitor, but actually perform updates by committing the newer Drupal and modules versions directly into the project's Git repository. In this article, we'll familiarise ourselves with the basic Drop Guard concepts, and go through the update behaviours configuration process to secure our website.
With this post, we are starting a new series - "Drop Guard recipes". It will be all about things which help us to be more productive, efficient, provide better service to our customers and ensure better security for Drupal. As you might expect, it will be mostly Drop Guard related, but we promise there will be a lot of interesting stuff for everyone. Stay tuned!
First of all, let's agree that if you or your team uses some sort of modern development workflow - which essentially means the path the code makes from the point it was originally written to the production website, you should be familiar with feature branches concept. Apart from traditional "dev", "stage" and "master" branches, you create separate named branches for website features or code updates which are not yet ready to be merged upstream.