This is Lesson 1 of Deploying a Drupal 8 Application.
In this lesson we will:
- Review the role of automated testing
- Review the role of human review
- Review the concept of “production as an artifact”
- Create a production ready artifact
Review the fundamental quality assurance and deployment processes.
In order to complete this lesson you will need:
- A Drupal 8 application that is ready to be reviewed and deployed
The following tools are not required, but are recommended:
Prerequisite QA process
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 Acquia 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 the Resources section below.
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, and test in a non-production environment prior to moving to production. 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 Acquia Cloud Pipelines functionality and is our 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. Drupal 8 applications should not be deployed by merely uploading a site via FTP or pushing a tag via Git. Instead, Drupal 8 should be deployed by executing a build process that transforms your development “source” codebase into a production-ready artifact, though again the changes need to be tested in a non-production environment first.
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 8 codebase 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, not all of these 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.