Information for: DEVELOPERS   PARTNERS

Remote Administration FAQ

This page contains a list of frequently asked questions about Acquia Remote Administration (RA) and Automation processes.

What if I did not get a ticket?

Only websites that are compatible with automation will get a ticket within the 24-48 hour window. If your subscription did not get a ticket, ensure that your RA Preferences are set to Inform Only or Full Deploy. If your preferences are set correctly, contact Acquia support. It is possible that the subscription is not compatible with automation, or automation was unable to complete the update due to an error. We will likely have an internal log of this error, and can assist with troubleshooting. Premium RA clients are eligible for manual updates.

What if my subscription is not compatible with automation?

The answer to this question is based on your subscription level:

  • RA Standard - Compatibility with automation is the responsibility of your development team.
  • RA Premium - Acquia Support Engineers can assist you in troubleshooting and modifying your codebase to ensure that it is compatible with automation.

Can I schedule when my updated code is pushed to production?

Yes. For more information, see Scheduling Production deploy windows.

How many security updates per year will affect any given website?

Drupal websites may require two types of security updates: updates for Drupal core, and updates for Drupal modules.

To give you an idea of the number of core updates per year, in 2014 the Drupal Security Team announced core security releases in November, October, August, July, April, and January.

Drupal modules are subject to security updates at any point in time, as they are maintained by individuals or small groups. All modules are constructed differently, by different people. As a result, we cannot extrapolate how often updates might be necessary for your website. Also, most Drupal 7 modules, at this point in Drupal 7’s lifecycle, do not often need security updates.

How often does the RA team check for security updates?

The Remote Administration team monitors for security releases based on the Drupal Security team’s schedule. Security release windows for Drupal are based on the following timeline:

  • Drupal contributed projects - Every Wednesday
  • Drupal core - One Wednesday a month (usually the third Wednesday)

A release window does not necessarily indicate that a release will occur on that date, but it exists so that site administrators can know in advance which days they should be aware of a possible security release. In the unusual case of a highly critical security issue, such as one which is being actively exploited in the wild, releases can occur outside of the normal release window.

If we are aware of particularly hazardous security updates available for common modules, or during long gaps between Drupal core security releases, we will periodically proactively contact RA customers to inform them that some module security updates are pending that we can perform.

What is the delay between Acquia detecting a security update and Acquia creating the branch and deploying on RA environment?

Acquia usually begins initiating updates within one day of a security release’s availability. Depending on the complexity of the release and number of customers who want it, our semi-automated systems are usually able to update all Remote Administration customers within 48 hours of the release.

Is it typical for customers to bundle security updates, regression testing, and deployment to production in batches?

For customers who cannot deploy new code to Production on-demand for various reasons, a quarterly release timeline generally works well. This gives them time to shift resources and schedule their testing and deployment accordingly. Some customers require immediate deployment of all security changes, in which case the update may need to be self-applied and deployed.

Generally, we can neither prioritize certain customers over others or predict when our semi-automated scripts will hit certain subscriptions in our list. Because of this, depending on the complexity of the update and number of customers responding to pending updates, one update could see your subscription having an update applied and deployed to your RA environment within a few days, while another update could take one to two weeks.

We recommend that customers test core updates first, and then apply and test module security updates one at a time. This ensures core security, and saves effort if issues arise that require the changes to be reverted module-by-module.

In the case of particularly hazardous Drupal core updates, we will note in our communications that they must be deployed as soon as possible, and explain why. If we are aware of a particularly hazardous module security update, we will also notify customers. This happens less frequently, and the burden of monitoring falls on the customers who are using specific modules.

May I use the RA environment as a mirror for my Production environment?

The RA environment is provided as a mechanism for Acquia’s RA team to deploy security-related updates in a semi-automated fashion for testing by customers. This is done using Acquia automation, and we do not expect any customer code or database deployments to use that environment.

The majority of RA environments are on shared hardware, which other customers are using for testing their updates. To not overload the shared hardware, at any given point in time we are working only with a limited number of customers on these servers.

Can RA automation work with large multisites?

For subscriptions that include a large number of websites, RA can specify a subset of websites included in those multisites to check for updates. Checking only a subset of websites in a multisite speeds up the RA process, and minimizes problems during automation caused by large numbers of database copy and backup tasks.

Where possible, customers should avoid installing different modules for individual websites in a multisite. Modules should be placed in the sites/all/modules folder.

Note

Drupal 8 websites created or maintained using Composer do not support the installation of modules for individual websites in a multisite.

When will I receive my updates?

The RA automation queue is generally run once a week, timed to accompany SA announcements (typically on Wednesdays). You should receive an update within 48 hours of initiation of an automated run. For details about when updates occur, see Ticket timelines.

How long does the update process take?

The security update process works at the speed of your team, and depends on your team following the recommended workflow.

Will declining to use an update branch affect future updates for us?

Declining to take action on any specific update branch issued by the RA team will not affect future updates. Any security updates not acted upon and promoted to Production before the next run of Acquia automation will result in an update branch that incorporates all available security updates.

Why does RA deploy the WELCOME tag on the RA environment?

At the end of Step 3, RA attempts to redeploy the WELCOME tag and drop all tables in RA environment’s database for security reasons. Leaving a tag containing functional Drupal code, but no database tables, on an environment leaves that environment open for others to create a new website with any administrator credentials they choose.

Who is responsible for testing the updates during step 1, 2 and 3 of the process?

RA does not test security updates at any point during the update process. If you encounter issues during your testing, you must report them in the update ticket, and a member of the RA team will investigate the issue. For more information about what kind of testing to perform during each step of the process, see Testing Remote Administration Updates.

How does RA handle patched core or modules during the update process?

RA will attempt to apply your patches if they are referenced or placed correctly in your code repository, as described in Patching core and contributed modules. For more information on Drush patching, see Patching and locking modules.

For websites built with Composer, install cweagans/composer-patches and reference all patches in your composer.json file. You can include patches from Drupal.org directly, or by placing a patch file in a patches directory above the docroot directory.

How does RA handle merge conflicts during step 3 of the update process?

If RA’s automated update process cannot complete a merge of the RA update branch back into your preferred development branch, a member of the RA team will attempt a manual merge of the branch. If we encounter a conflict, we will review the conflict, and depending on the nature of the conflict, RA may attempt to complete the merge using a merge strategy.

In the merge strategy, RA will decide whether to resolve the merges in favor of the versions contained in the currently-deployed branch, or in the new branch. This decision will be applied to all files with merge conflicts.

If a merge strategy does not resolve the conflicts, or if you would prefer to review each conflict and decide which version of a file to keep, then you or your development team must resolve the merge conflicts.

Merge conflicts are otherwise out of scope for RA.

Does RA support Drupal 7 websites built using Composer?

RA does not support Drupal 7 websites built with Composer at this time.