Information for: DEVELOPERS   PARTNERS

Preparing for Production

Lesson Goal

Review the fundamental quality assurance and deployment processes.

In order to complete this lesson you will need:

  • An application running Drupal 8 or greater that is ready to be reviewed and deployed.

The following tools are not required, but are recommended:

In this lesson we will:

  1. Review the role automated testing
  2. Review the role of human review
  3. Review the concept of “production as an artifact”
  4. Create a production ready artifact

When deploying your code to production, you should have a high degree of confidence that your application works as intended. Having a development workflow that includes quality assurance (QA) is the best means of instilling this confidence.

If you are using a continuous integration workflow, you have the opportunity to perform quality assurance continuously. You will have tested and reviewed your codebase throughout the development process. This reduces the burden of deploying your code to production by preventing QA debt from accumulating.

At a minimum, your QA process should include both automated testing and human review. A brief overview of these topics is covered below.

Prerequisite QA process

Automated test robot

Automated Tests

Your Drupal application should have a suite of automated tests. These are custom to your application and they serve to assert that your application works the way that you and your users expect.

Do not fall prey to common rationalizations and excuses relating to insufficient time, money, or resources. Time spent developing tests will yield future rewards exponentially. “The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten.” (Karl Wiegers)

If you are not already using a testing framework, we recommend using BLT. Acquia BLT provides a testing framework which enables you to quickly write and execute automated tests using two popular testing tools: Behat and PHPUnit. To learn more about these tools and how to implement them on a Drupal application, review this tutorial’s Resources section.

People reviewing plans

Human Review

Human review remains an essential component of quality assurance, even with a robust suite of automated tests. There will always be issues that only a human can catch.

Ideally, you will review code changes continuously throughout the development process. There are many SaaS tools that enable you to do this by providing interfaces for reviewing and discussing code changes. Popular tools include GitHub, GitLab, and BitBucket. At present, GitHub is directly integrated with the Cloud Platform pipelines functionality and is the recommended code collaboration tool.

In fact, you can use GitHub to enforce the practice of code review. See Enabling required reviews for pull requests and Protected Branches to learn how you can require this practice when using GitHub.

Production is an artifact of development

With the adoption of Composer in Drupal 8, the process of deploying a Drupal application has fundamentally changed. Applications running Drupal 8 or greater shouldn’t be deployed by merely uploading a site via FTP or pushing a tag using Git. Instead, your application should be deployed by executing a build process that transforms your development “source” codebase into a production-ready artifact.

This concept may be new to the Drupal community, but it is a well established practice in software development. Much in the way that an iOS or Java app needs to be compiled, a Drupal codebases should be “built” for production.

The underlying principle: production is an artifact of development. Put differently, the things that you need to run your Drupal site in a production capacity are not the same things that you need to develop your Drupal site locally. For instance, you may use a suite of tools like Drush, Devel, Views UI, PHP CodeSniffer, SASS, etc., to develop your Drupal application. These are tools used to produce your site, but they are not your site, and hence these things do not belong on your production server.

The build process is intended to take your development “source” code and produce an artifact that is production ready. Often, this means removing development-only packages, sanitizing your codebase, and optimizing your application for performance.