Information for: DEVELOPERS   PARTNERS

Generating a deployment artifact

Deploy – Back to intro
Previous lesson - Preparing for Production
Next lesson – Release the Kraken

Lesson Goal

Generate a production-ready deployment artifact for a Drupal 8 application.

In order to complete this lesson you will need:

  • A Drupal 8 application that is ready for deployment
  • Access to an Acquia Cloud subscription
  • Composer
  • PHP 5.6+
  • Git

The following tools are not required, but are recommended:

In this lesson we will:

  1. Generate a deployment artifact
  2. Push the artifact to Acquia Cloud

As discussed in lesson 1, deploying a Drupal 8 application to production requires producing a “deployment artifact”. This lesson will walk you through creating that artifact.

Manual approach

For those not using Acquia BLT, you should at a minimum use Composer to remove development dependencies and optimize your application’s autoloader:

composer install --no-dev --optimize-autoloader

This will install only the dependencies in your composer.json’s “require” array (not in the “require-dev” array) and will optimize Composer’s autoloader, which significantly improves application performance.

You should also consider performing the following manual steps:

  • Remove Drupal core text files, like CHANGELOG.txt, from your docroot. These can inadvertently reveal your exact Drupal core version to malicious site visitors.
  • Change/Restrict any reachable path for security purposes (i.e. node_modules or similar).
  • Compile front end source code (like SASS) into front end assets (like CSS).

After you’ve manually prepared your codebase for production, you will need to create a new Git tag.

Cutting Tags

Using a git tag for deployment is a best practice because tags are immutable. In other words, after it has been created a tag cannot be changed. For instance, using a tag will prevent someone from accidentally pushing a new commit to a branch that is deployed to your production environment. This cannot happen with a tag.

git tag 1.0.0 -m 'This is the first major release!'

Now that your tag is cut, you can simply push it to Acquia Cloud:

git push origin 1.0.0

Naming your releases

You should use a naming convention for your tags that works well for your team. The most popular (and recommended option) is Semantic Versioning (semver). In short, semver provides a set of rules for naming tags. The rules help you track:

  • The order in which releases are made
  • Releases that introduce backwards incompatible changes (major)
  • Releases that introduce new, backwards compatible functionality (minor)
  • Releases that provide backwards compatible bug fixes (patch)

Tags using semver take the form MAJOR.MINOR.PATCH. For more information, see

In combination with Composer version constraints, you can use semver to ensure that your application’s dependencies are never accidentally updated to a backwards incompatible version.

Now that you have a deployment artifact, you’re ready to deploy it on your Acquia Cloud production environment!

Next Lesson > Release the Kraken (code)

In this next lesson we will deploy a production-ready deployment artifact to Acquia Cloud.