Cloud Platform
Lesson 1: Preparing for Production - Deploying a Drupal 9 Application
This is Lesson 1 of Tutorial: Deploying a Drupal Application.
Review the fundamental quality assurance and deployment processes.
In order to complete this lesson you will need:
Your Drupal application should have a suite of automated tasks, including automated testing frameworks, project automation tasks, deployment artifact generation, Continuous Integration and deployment.
These are custom to your application and they serve to verify 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 popular testing tools, such as Behat and PHPUnit, Travis CI, composer and Acquia Pipelines and Acquia CLI.
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 Pipelines functionality and is our recommended code collaboration tool.
In fact, you can use GitHub to enforce the practice of code review. See Managing a branch protection rule and Protected Branches to learn how you can require this practice when using GitHub.
Important
Review Working with code at Acquia and ensure you test in a Dev or Stage (non-Production) environment before releasing to Production.
Always take a database backup in Production before deploying code.
"Built for Production" or "Production-ready" does not imply skipping testing in a non-Production environment first.
With the adoption of Composer in Drupal 8, the process of deploying a Drupal application has fundamentally changed. Drupal applications, of version 8 and above, should not be deployed by merely uploading a site via FTP or pushing a tag via Git. Instead, Drupal 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, 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.
Cloud Platform