Deploying a Composer Managed Drupal application
- Last updated
- 1 minute read
Goal
Deploy a Composer-managed Drupal application to a hosting environment
Prerequisites
-
A Composer-managed Drupal application
-
Deploying a Composer Managed Drupal application
Acquia and Composer best practices dictate that you should not commit Composer dependencies (like
vendor
,docroot/core
,docroot/modules/contrib
, etc.) to your git repository.You may ask yourself: "If I don’t commit them, how do I deploy them to a hosting environment?" That’s a good question. To answer it, let’s talk about a common and fundamental software development concept: production as an artifact of development.
Many software languages compile source code (used during development) into an artifact (used during production) using a build process. For example:
- SASS and LESS are compiled into CSS
- Typescript and REACT JSX are “transpiled” javascript
Why do this? In short, because you want your hosted Drupal site to be slim, fast, and secure. Your production environment should not contain any development tools or configuration. The things that you need to develop Drupal are not the same things that you need to run Drupal.
For example, you make use any one of the following tools during development and testing of a Drupal application:
- Local environment configuration, like a Dockerfile or Vagrantfile
- Code quality tools like PHP Code Sniffer
- Front end tools like SASS, LESS, Gulp, Grunt,etc.
- Testing tools like Behat, PHPUnit, etc.
You shouldn’t ship these tools or their configuration to your production environment!
Let’s visualize the difference between your "source code repository" and the "artifact" that you will actually deploy to your production environment.
Note two things:
- The development "source code" contains config files for development tools that are not present in the artifact.
- The artifact contains upstream dependencies (like modules, Drupal core, etc.) that are not committed to the “source code” repository.
-
How to create an artifact
Acquia offers two methods for generating Drupal artifacts: Acquia CLI’s
push:artifact
command and Acquia BLT’s deploy command. Using Acquia CLI is simpler and is therefore Acquia’s preferred method.Acquia CLI’s
push:artifact
command generates an artifact and pushes it to a git remote. What exactly is the difference between the source code and the produced artifact? Here are a few of the more important differences. The push:artifact command will:- Install only the
require
Composer dependencies (not any of therequire-dev
dependencies) - Optimize Composer’s autoloader, making PHP execution up to 37% faster
- Remove
.txt
and.md
files that are superfluous and may allow bad actors to identify your exact Drupal version - Remove nested
.git
directories that may cause issues with committing dependencies
If you use Acquia Code Studio, the
deploy
stage of the AutoDevOps pipeline will execute this Acquia CLI command for you.Try it yourself
cd [path/to/your/repository] acli push:artifact
- Install only the
Additional Resources
- Tutorial: Creating a new Drupal application with Composer
- Tutorial: Deploying a Composer Managed Drupal application
- Should I commit the dependencies in my vendor directory?
- Using Composer to Install Drupal and Manage Dependencies
- Recommended Drupal project for use on Acquia Cloud
- Minimal Drupal project for use on Acquia Cloud