There is no single deployment command that fits every Drupal application on Acquia Cloud. A release may contain code, Composer dependencies, database update hooks, configuration changes, or all four. The correct sequence depends on the application, its automation, and whether the change is backward-compatible.
This checklist is a baseline for a conventional Drupal application whose configuration is exported to the repository. Adapt it to the project’s release tooling and test it outside production first.
Prepare a releasable artifact
Review and test the exact commit or tag that will be promoted. Commit composer.json, composer.lock, exported Drupal configuration, and any deployment scripts that belong to the release. Do not rebuild dependencies differently in each environment.
Before promotion, write down:
- database updates the release introduces;
- configuration that will be imported;
- cache or search-index work required afterward;
- any maintenance window or maintenance-mode requirement;
- the recovery point and the code version to redeploy if validation fails.
Configuration is not content. Avoid copying a lower-environment database into production. When production data is copied down for testing, follow the organization’s rules for personal or sensitive data, sanitize it where required, and keep it out of developer laptops and logs unless authorized.
Prove the release in a non-production environment
Deploy the same artifact intended for production to the QA or staging environment. A useful sequence is:
- Back up the target database before changing it.
- Deploy the code artifact.
- Run database updates:
drush updatedb -y. - Import exported configuration:
drush config:import -y. - Rebuild Drupal caches:
drush cache:rebuild. - Run smoke tests, automated tests, and application-specific checks.
Some teams import configuration before update hooks, and some releases need more specific ordering. Decide that ordering from the dependencies in the release, then automate the same sequence in every environment. Acquia Cloud Actions and deployment hooks can perform these tasks, but the team still owns their ordering and failure behavior.
Test login, permissions, critical forms, integrations, queues, scheduled work, and representative content paths. Check logs as well as the browser. If the release changes search, queues, or external schemas, test those operations explicitly.
Promote to production
Use the tested tag or artifact rather than rebuilding from a moving branch. Before deployment, confirm the database backup completed and record the currently deployed code version. Pause deployments and content-changing jobs that would conflict with the release.
Run the documented release sequence. Keep the deployment log. Afterward, verify Drupal status, critical user journeys, integrations, queues, cron, and recent error logs. Clear downstream caches or CDN layers only when the release requires it; broad cache clears can add avoidable production load.
Recovery is part of deployment
Reverting code does not reverse a database update or configuration import. If a change is not backward-compatible, recovery may require restoring the pre-deployment database and files as well as redeploying the previous code tag. That can discard content created after the backup, so the decision and communication path should be agreed before release.
Prefer forward fixes for small, understood problems when they are safer than a data restore. For a failed structural change, stop, preserve logs, and follow the tested recovery plan rather than improvising in production.