Information for: DEVELOPERS   PARTNERS

Generating a deployment artifact

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

Lesson Goal

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

In order to complete this lesson you will need:

  • An application running Drupal 8 or greater application that is ready for deployment
  • Access to a Cloud Platform subscription
  • Composer
  • PHP 7.3+
  • 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 Cloud Platform

As discussed in lesson 1, deploying an application running Drupal 8 or greater 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 directory. These can inadvertently reveal your exact Drupal core version to malicious site visitors.
  • Change/Restrict any reachable path for security purposes.
  • 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 push it to Cloud Platform:

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 Cloud Platform production environment!

Next Lesson > Release the Kraken (code)

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