One of the struggles developers face when moving to Drupal 8 is the lack of best practices in deploying Drupal sites. The challenges in deployment revolve around dependency management, drupal contrib modules/themes, configuration management and of course the code base.
There is no such problem in Drupal 7. But ah, Drupal 8 brings with it a lot of things to manage. One of the biggest changes in Drupal 8 is the adoption of Composer. Good things come at a price.
We will use one codebase for a Drupal site and use Git for version control and deployment.
Composer is a dependency manager for PHP (like npm for Node or pip for Python). Drupal uses Composer to manage core Symfony components and core dependencies like Guzzle. Composer allows us to systematically manage the list of dependencies and their supporting dependencies.
It detects, downloads, validates and loads packages. It also ensures that the exact correct versions are used for each package, and maintains a log file called composer.lock.
Note: Always commit your composer.lock file, as it contains the exact version of the dependency that you have defined in the project.
You should never run composer update, as composer will try to update each dependency. This can cause problems with your site.
This will automatically set up a Drupal site with all the dependencies. It will also install drupal console and drush locally.
Composer is one of the fastest ways to install dependencies, as it caches the dependencies and loads the data from the cache next time.
This is different from the Drupal directory structure. You can recompile the web directory with the public directory containing the Drupal files. All third party dependencies are outside the web folder.
You can install any Drupal module, theme and profile through composer which will be downloaded in contrib folder inside module, theme and profile respectively. This way, the composer.lock file will contain a record of all Drupal contrib modules along with third party dependencies.
Deployment and configuration management are common actions of a project life cycle. We have installed various modules and configured our local site, but there is no such configuration in our production site.
In Drupal 7, we had the Features module, which is used to sync configurations. But Drupal 8 has a built-in solution for managing configuration. It allows you to export entire website configurations and store them in YAML files. The exported files can be imported to any other website with the same result.
Drupal’s configuration system helps solve the config file synchronization problem in two ways: a unified way to store configuration, and a process to import/export changes between instances of the same site.
manage environment configuration
My favorite aspect of Drupal as a developer is its ability to manage various environment configurations. This can be done using the vlucas/phpdotenv module, which also comes with the Drupal composer template.
Anything that is likely to change between deployment environments – such as database credentials or credentials for third party services – should be extracted from code into environment variables. Basically, an .env file is a simple way to load custom configuration variables that your application needs without modifying any other files.
Rename .env.example to the .env file and add all the credentials as key-value pairs to the .env file.
The load.environment.php file will load this .env file and make it available to you.
Now, since all our credentials are stored in the .env file, we can push our settings.php to the server and manage its configuration through the .env file.
We usually enable twig debugging during development and disable it on production.