Drop Guard recipes: Testing your updates in a feature branch instance
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.
As usual, feature branches are manually created, maintained, tested and merged back for the final integration testing and deployment. That’s their lifecycle.
To branch or not to branch
Let's be honest - for small and medium sized projects this procedure consumes so much time, that a common practice (but not the best one) is to branch only the most critical, important or potentially disruptive features. Minor fixes, changes and most importantly - Drupal core and modules updates are usually pushed directly to "dev" or "stage" environments for the immediate testing.
Certainly, it saves time, but it can also cause delays in production process; and even more difficulties, such as:
Very often there is a change in module's theme layer, API or compatibility with other contribs, which can literally break the website or a great part of it;
The module release may contain bugs or other issues which need time to be properly fixed by writing a patch or crawling through the Drupal.org issue queue. For bigger issues, community needs a few days to weeks to prepare a solution;
When going from dev or unstable to recommended release you want to spend more time on ensuring things are working as expected.
In case the module update was committed directly to one of the pre-production branches, it typically blocks the deployment of other features until you resolve all the issues in the main branch. Being blocked from the deployment by the contrib update issue is no fun and very annoying. Cherry-picking commits and branches for deployment can be an option, but it consumes time as well.
Solution? Create feature branches for each update or a group of related updates.
Here is how it should work according to the best practices:
1. Create feature branch for each non-security update (and depending on your expertise - for all non-critical security updates). If the updates are related it's safe to group them in one branch;
2. Assign the update task for the responsible developer in your project management system;
3. Create a feature branch instance for this update so that your team can immediately start the review process once the update was applied;
4. Perform an update and run automated and manual tests;
5. Once everything is working and confirmed to be ready for deployment, merge the feature branch back to the development branch and run tests again. More tests never hurt!
6. Finally, deploy to production.
Sounds like a lot of work, right? Indeed, there are a lot of steps, but they are here for a purpose - to ensure the update goes as smoothly as possible and the production website will not suffer afterwards. Good news is that many things can be automated nowadays, so we will not have to sacrifice the quality to meet the deadline.
Drop Guard to the rescue
Drop Guard can be a real time-saver when working with feature branches. Below is one of the possible scenarios which you can use.
1. Configure the update behavior for the "Normal updates" so that once Drop Guard detects a non-security update for a project, it spins up a feature branch instance for the update.
Specify the source branch to create a feature branch from; and set the testing mode to "Manual tests" which means the update task in Drop Guard will not be closed until you confirm, manually or automatically, that all tests have been passed.
2. Configure the action for the "Test passed" event so that when all tests are done, and you are satisfied with the result, the branch will be merged back automatically.
3. Let your CI server or system to create a feature branch instance (a separate website installation) out of that feature branch. This step is optional if you don't create instances for your feature branches, or your CI server creates instances for all your feature branches automatically.
4. In the same fashion, send an email to the responsible person, and (or), let your project management system to create a task or an issue.
5. Once everyone is happy with the update, we change the task status to "Test passed" and let Drop Guard to take care of the rest automatically - merging branch, sending notifications, pinging the CI, running Drush commands - whatever you choose.
Such workflow should only be configured once, and Drop Guard will start following it for each new update. Surely enough, you can configure more sophisticated or more simplified workflow - it's up to you!
Create feature branch instance for your updates
This part is optional. In many cases, it is sufficient for a developer to check out the feature branch on his local machine, perform an update and run tests.
However, if you want to automate all the things, there are basically two options:
1. Create and maintain your own infrastructure for spinning up feature branch instances.
There are a lot of ways of accomplishing this, and all of them are outside of the scope of this post. If you feel adventurous, you can give Woodby a try - this Docker-based service allows to automate many things if you decide to choose this path.
2. Use full-featured continuous integration tool which does all the job for you. We have selected two most promising services in our view, but you are free to choose any Drupal-specific or more general one which suits you best.
Probo allows to create test environments for each new feature as the team develops so that everyone (QA, project managers, developers) can see and interact with development changes earlier and more frequently throughout development without waiting for an environment update.
Targeted mostly to enterprise teams (and, as a result, a bit costly), Tugboat aims to automatically and blazingly fast build previews of the website when changes in the repository are made. We haven't tested it yet, but if the price is not a concern, we highly recommend giving this tool a try.
Whatever path you choose, should you decide to integrate Drop Guard or other tools in your workflow, or do everything by yourself, you should learn how to use feature branches effectively, particularly for the codebase updates. As easy as it sounds, but ignoring best practices, deciding to work in a manner which has served well enough in the past, can cause a lot of trouble.