Automation
Automation delivers Remote Administration security updates. Acquia
Remote Administration automation uses Preferences, and has
specific compatibility requirements.
Compatibility requirements
Meeting the following requirements allows a website to be updated by using
Acquia’s automated security update process:
- VCS: The subscription must use an Acquia Git repository. Automated
security updates are pushed to the Acquia-hosted repository only. It’s the
responsibility of your development team to merge updates into any external
repository.
- Subscriptions using externally hosted Git repositories are not eligible
for automated security updates.
- Clean core and contrib: The automated update process will overwrite
core and contributed files, and any modifications will be lost. Modified
contributed modules should either be excluded from the update process or
correctly patched. Drupal core updates can’t be
locked and all modifications must be patched or they will be lost.
- Stable and working production code: The Remote Administration
service is targeted at released, production websites on which primary
development is complete. Installations running the Welcome tag
(
tag/WELCOME
) can’t receive automated updates. It’s recommended that
your development team apply upgrades to websites under current and active
initial development as part of the development process so issues may be
resolved as they arise and unnecessary merge tasks can be avoided. Websites
in active development may be updated provided there is code on the
Production environment. Your development team will need to merge updates
from the update branch into the active development branch.
- Composer: For compatibility with RA automation, Acquia recommends that
Drupal 8 and Drupal 9-based websites must be built using Composer.
Drupal 9.x websites also require Drush 11.x or later to be installed in the
docroot directory with Composer. RA cannot guarantee the compatibility of
Drush updates provided to Drupal 9.x websites. For information about how to
set up Composer for your website, see Acquia Automation: Composer builds.
- Drush: Drush must be able to run on at least one multisite within
the subscription and must work on all available environments. Broken custom
modules or incorrectly configured
include
files in the sites.php
and
settings.php
files can prevent automated update processes from
functioning.
- Drupal 7: The command
drush pm-updatestatus
and
drush pm-updatecode
must be able to be run on all environments.
- Drupal 9: The command
drush pm-security
must be able to be run
on all environments.
- Drupal docroot: Drupal must be installed inside
[reponame]/docroot.
Installations not in this location will prevent automated update processes
from functioning. Appropriately configured symlinks using a vendor
structure that works with Drush are also acceptable.
- PHP: The Remote Administration update script relies on the following to
check and perform updates:
- Drush 8.x or later
- PHP 7.4 or later
- Distributions that aren’t compatible with Drush updates can’t be updated
using automation.
Note for Legacy Premium RA subscribers
Acquia can help troubleshoot incompatibilities with automation and help
implement fixes through an Acquia Support ticket.
What Acquia’s update automation does
Regularly provides security updates without subscriber initiation.
Updates all security vulnerabilities using Drush or Composer. Be aware that
Drush overwrites all core and contributed module modifications.
Detects non-Drupal files in the docroot directory, and ensures they are not
deleted.
Including security updates, Acquia will implement bug-fix updates to
the following modules, even if the modules are disabled, to ensure your
subscription can take advantage of Acquia’s services:
Note
The Remote Administration module upgrade policy may not apply to Acquia-supplied modules,
as RA may support major version updates for these modules (such as
upgrading Acquia Connector from 7.x-2.17 to 7.x-3.0). This ensures
continued compatibility with RA services and the Cloud Platform.
For some Acquia module update situations, RA may create non-deployed
branches with the module for your testing. For more information,
contact Acquia Support or create an RA
work request.
Implements Stage File Proxy to manage file
display.
Checks and reapplies patches in your application, and includes them in all
updates. For this to work, you must follow the process described in
Patching core and contributed modules. It’s
your responsibility to ensure that patches are in place on the update
branch.
Informs you through a ticket that an update is ready to test. The ticket
outlines all applied updates.
What Acquia’s update automation doesn’t do
- Automation does not apply bug-fix updates other than those listed above.
- Update automation won’t detect modifications to either core or contributed
modules. All modifications must either be locked or properly patched.
- Apply existing patches other than those specified in
/reponame/patches.make. All other patches will be
overwritten by Drush unless module locking is also properly set up.
- Update websites built on distributions.
- Update websites built with make files or build scripts. Custom builds
dependent on manually updating individual files are considered custom code
and cannot be updated through automation.
- Update websites built using Continuous Integration (CI).
Who receives automated updates
Note
Subscribers who are undergoing onboarding as part of an Acquia Ready
engagement are not provided with updates by default. Automated updates
can be provided on request by your Acquia Ready Manager or engineer,
or by filing a Support ticket.
All Standard and Legacy Premium RA subscriptions are eligible for automated
security updates, provided the subscription is compatible with Acquia’s
automation.
- Security updates for Standard RA subscriptions must use automation.
- Acquia can’t guarantee a security update delivery timeline for subscriptions
which aren’t compatible with Acquia’s security update automation.
Update process
The automation process follows our existing Security Update Workflow. For the timeline about initiating security updates, see
ticket timelines.
After a website is queued for an automated update, the script will:
- Scan the production website for pending security updates.
- If a security vulnerability is detected, an update will be started.
- RA Preferences for the subscription will be reviewed.
- If RA preferences are set to Update Code, a branch will be deployed
to the RA Environment, updated, and a ticket will be sent to your team.
- If RA preferences are set to Inform Only, a ticket will be sent
listing recommended security updates. You may request an update by
changing your RA preferences and resolving the ticket. The RA process
will update the codebase in the next weekly run.
- An updated branch will be available for testing within 24 to 48 hours of a
Security Announcement on drupal.org. After a
branch has been deployed, progress on the ticket is dependent upon
subscriber testing through all steps of the RA security update workflow.
- If an update branch already exists, unless a new security update is
announced, you won’t receive a new ticket for two weeks.