Acquia Platform and Deployment Workflow
What to know
Acquia Cloud provides environments (dev, stage, prod) on a subscription. Code flows via Git (or pipelines) from a repository; each environment has a branch. Acquia Cloud IDE offers a browser-based dev environment. Pipelines (Acquia Pipelines / Cloud Platform pipelines) run build, test, and deploy steps defined in YAML.
Configuration management is central: drush config:export writes YAML to config/sync; drush config:import applies it. In CI, the standard flow is build artifacts, run tests, deploy code, then import config. Composer manages dependencies; composer install --no-dev in production. Drush is the CLI for cache rebuilds, updates, and config.
Acquia Cloud Hooks (hooks/common/post-code-deploy/, post-db-copy/) run scripts on events. Database copies move data between environments; config should still be imported, not copied, to avoid drift. Backups are scheduled; Acquia Search, CDN, and Varnish are managed services.
Traps
- Code vs. config vs. database: code deploys via Git; config via import; database via copy. Questions test which artifact moves where.
- Config import order: import after code deploy so new config schema exists.
--no-dev: production installs omit dev dependencies.- Cloud hooks vs. Drush: hooks are event scripts; Drush is manual CLI.
- Environment drift: copying the database does not sync config; always import.
Rule of thumb
Deploy in this order: build with Composer, deploy code, run database updates (drush updb), import config (drush cim), then clear caches (drush cr).
Worked example
A new field is added locally: export config, commit YAML, push to the environment branch. The pipeline deploys code, runs drush updb (for schema), then drush cim, then drush cr-never copy the database to move the field.