What if I did not get a ticket?¶

Only websites compatible with automation will receive a ticket within the 24 to 48 hour window. If your subscription did not get a ticket, ensure you set your RA Preferences to Inform Only or Full Deploy. If your preferences are correctly set, contact Acquia Support. Your subscription may not be compatible with automation, or automation can’t complete the update due to an error. RA will likely have an internal log of the error, and can assist with troubleshooting. Legacy Premium RA clients are eligible for manual updates.

What if my subscription is not compatible with automation?¶

Your subscription level determines your compatibility with automation:

• RA Standard: Compatibility with automation is the responsibility of your development team.

• Legacy Premium RA: Acquia Support Engineers can assist you in troubleshooting and modifying your codebase to ensure compatibility 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 security updates for Drupal core, and security updates for Drupal modules. The Drupal Security Team provides the following security release windows:

• Drupal contributed projects: Every Wednesday

• Drupal core: One Wednesday a month (typically the third Wednesday)

Acquia cannot estimate how frequently your website may need updates, as there are many members of the Drupal community that develop and maintain contributed modules, but you must take the security release windows into consideration when developing your application.

For a list of recent security advisories, see Security advisories on Drupal.org.

How often does the RA team check for security updates?¶

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

• Drupal contributed projects: Every Wednesday

• Drupal core: One Wednesday a month (typically the third Wednesday)

A release window does not necessarily mean a release will always occur on that date. They exist so you can plan in advance for the possibility of a security release. In the unusual case of a highly critical security issue, such as an actively-exploited zero-day issue, releases can occur outside of the normal release window.

If the RA team is aware of particularly hazardous security updates available for common modules, or during long gaps between Drupal core security releases, we will periodically contact RA subscribers to inform them of available module security updates we can perform.

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

Acquia typically begins initiating updates within one day of a security release’s availability. Depending on the complexity of the release and number of subscribers who want it, our semi-automated systems can typically update all RA subscribers within 48 hours of the release.

Do subscribers typically bundle security updates, regression testing, and deployment to production in batches?¶

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

Generally, the RA team can neither prioritize certain subscribers over others, nor predict when RA semi-automated scripts will reach certain subscriptions in RA’s list. Depending on the complexity of the update and number of subscribers responding to pending updates, one update may allow you to have your update applied and deployed to your RA environment within a few days, while another update could take one to two weeks.

We recommend you test core updates first, and then apply and test module security updates one at a time. This approach ensures core security, and saves effort if you encounter issues that require reverting the changes module-by-module.

In the case of particularly hazardous Drupal core updates, we will note in our communications you must deploy them as soon as possible, and explain why. If we are aware of a particularly hazardous module security update, we will also notify subscribers. This scenario happens less frequently, and the responsibility of monitoring is with the subscribers 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 you to test. Acquia’s automation expects that no other any customer code or database deployments will use that environment.

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

Can RA automation work with large multisites?¶

For subscriptions including many websites, RA can determine if there are updates on a specified set of websites included in those multisites. Examining only a subset of websites in a multisite speeds up the RA process, and minimizes problems during automation caused by many database copy and backup tasks.

Where possible, avoid installing different modules for individual websites in a multisite. Place modules in the modules/ directory for websites running the current Drupal version, and the sites/all/modules directory for Drupal 7 websites.

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 you do not promote to Production before the next run of Acquia automation will result in the next update branch incorporating 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’s environment database for security reasons. Leaving a tag that contains functional Drupal code (but no database tables) on an environment leaves the 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, follow the instructions at Patching with Composer to reference all patches either from Drupal.org or a local 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 to manually merge the branch. If there is a conflict, RA 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 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 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.

Can I schedule a deploy outside of standard business hours?¶

Yes, though Acquia recommends you schedule your deploy during standard business hours so a member of the RA team can assist you if there are any complications during the production deploy.

What do I do if there is a problem during or after a production deploy?¶

If you miss a deploy window, you can reply in the update ticket and a member of the RA team will follow up with you once available.

If you notice an issue on your production website shortly after a production deploy, reply to the RA update ticket. A member of the team can troubleshoot the issue, or revert your production environment to its previous state.

If the deploy takes place outside of standard business hours, file a critical support ticket and reference the existing RA update ticket. The RA update ticket must include useful troubleshooting information to help Acquia Support revert the production website to its previous state, such as:

• What tag was previously deployed on the production environment?

• What is the ID of each database backup created at the start of the deploy process?

RA has updated the package but Composer still reports it as a failure?¶

When RA runs Composer commands to update packages, Composer sometimes returns a warning even if the actual package update operation is successful. The warning leads to a failure status for the entire command. As a result, RA records the failure in the attached log file for further investigation.

In such cases, if the ticket details show the package version as updated, you must consider that as the source of truth and ignore the error in the log file for that package.

Why is an AURABot user added to my Cloud Next application?¶

Cloud Platform creates the AURABot user in your organanization-level team called RA-BOT-team. This user is required for the smooth functioning of the Remote Administration service that provides Drupal security updates to your Cloud Next environments on a weekly basis. Ensure that you do not delete this user. This user is visible only if you are using Remote Administration to deploy Drupal updates on your Cloud Next environments.