Drupal configuration migration

What is Drupal configuration migration? Many Drupaller are confused about this topic. New users do not realize this problem at the beginning of their work, and friends who are aware of this problem are not sure how to correctly configure the migration. This article systematically talks about the causes, methods, and methods of Drupal configuration migration and related modules.

If you are troubled by the following questions, it will be helpful to read this article carefully.

After modifying some site configurations (such as site names, banners, or any variable values in the variables table), how can I deploy them online at one time? How does one track each change record? (In most cases, have you directly modified it online: D)

In the development environment, the page layout is adjusted, and the block configuration (such as location and display conditions) and content are modified. How can we quickly deploy the block to the production environment (whether to manually adjust it one by one, redo what you have done-this is boring, time-consuming, and error-prone, especially when these configurations were previously configured by others, it will be very difficult to reproduce it accurately)

I have added several new fields, content types, input formats, Wysiwyg configurations, and views to the development environment. I don't want to perform manual operations online. What should I do if I have mouse or mouse punctuation?

During the development process, a large amount of actual data is required and cannot be directly operated online. How can we migrate the actual data from the online environment to the development environment?

......

Why does Drupal need to perform configuration migration?

Everyone is familiar with traditional Web Development. The main work is to deal with code. Almost all work, whether it is PHP, CSS, HTML or JS, is done in files. If you want to update or upgrade some features, you can upload the modified files after the backup, So Easy!

For Drupal, configuration migration is not that easy, because file migration is only a small part of Drupal configuration migration. Most of Drupal configuration exists in the database. Because the databases in the online environment are changing at all times, it is not easy to update the content of some databases in the development environment online without affecting the online content.

Drupal's existence of configuration in databases is often criticized by Drupal veterans-the biggest drawback is that you cannot simply migrate some values in the database or control the actual version, of course, the advantage of this design is that it facilitates developers to conduct R & D, and facilitates users to quickly provision features through the interface (without having to modify the code. (Again, Drupal chooses flexibility and sacrifices other things)

Before D8, Drupal did not have a uniform standard to regulate how everyone should store their own configuration data. The configuration formats and storage methods of different modules were different, therefore, it is impossible to migrate all configuration data in a specific way at a time.

(The configuration management system has been implemented in D8, and unified specifications and standards have been set for configuration management. For details, see Drupal 8 configuration management mechanism and new features.)

Another reason for Drupal's configuration migration to become a difficult topic is that before D8, Drupal's configuration and content were stored in a database, and it was difficult to separate the two, if you only perform operations by overwriting the database, you cannot change the configuration without touching the content, and vice versa.

Because of the design, Drupal configuration migration has become a difficult issue. Its workflows and solutions have become an independent, unavoidable and interesting topic.

Currently, Drupal configuration migration is very mature. For configuration migration before D8, refer to this article. You can learn about D8 configuration migration and use it skillfully. Although D8 does not have a uniform standard configuration management system before, many concepts of the D8 configuration management system are the same as the configuration migration methods mentioned in this article, therefore, learning this article will make it easier to understand the D8 configuration management system later.

Advantages of enhanced Drupal configuration migration automation

I believe many of my friends will first perform Drupal development locally and then perform it in the Test environment or production environment. Of course, this is also a method that can be applied to the function deployment of small sites. However, it takes several weeks or months to work online, the price of repeating a repeat is quite high-the premise is that everyone remembers what configuration was made in the whole time.

If you want to perform configuration migration tasks more easily, accurately, efficiently, and easily, you may wish to learn how to make configuration migration more self-reliant.

The following are some of the main advantages of automated configuration migration using various tools:

Workload reduction-the deployment of a large number of configurations can be done with mouse punctuation, which makes it much easier to upload files by simplifying a large number of click operations;
Lower error rate-people are often the main cause of errors, allowing the code to remember the first step can greatly reduce the error rate;
Version control-records the status and time of each configuration change, and easily restores the configuration to a backup at a certain time point;
Rapid deployment-the site cannot withstand long-term offline operations. It is a great sense of accomplishment to complete several weeks and months of updates within several minutes and within several seconds;
......
 

Common Configuration migration of Drupal

The reason for configuration migration is that the Web project has at least two environments: the engineer's local development environment and the online production environment. In general, standard Web projects involve "development-Test-online", that is, the popular Dev-Stage-Prod model (also known as Dev-Stage-Live ), a qa environment will be added when the problem is complex. Because of this, you need to configure the migration.

Later, we will use the Dev-Stage-Prod environment model to understand how to configure and migrate Drupal. This exactly represents our usual workflow-engineers conduct development in their respective regions, then deploy them to the test environment for centralized testing, correct them repeatedly, and then deploy them online.

What content does Drupal need to migrate and how to migrate?

After understanding the reasons for migration, let's look at the content to be migrated. As mentioned above, different configurations in Drupal have different migration methods. Using the correct tools and methods can get twice the result with half the effort.

Migration items	Storage location	Migration method
Module and topic	Module and topic file	Directly upload files
Environment variable	Database	Combine Features with the Strongarm module to package and then Upload
View, editor, content type, field, block	Database	Use the Features and Features Extra modules to package the files and then upload them.
* Terms, users, and other configuration dependencies	Database	You can use the Features, UUID, and UUID Features modules to package them into a file and then upload them. However, it is recommended that you first add the database to the online environment, and then download the database to the local for development. For more information, see the following section.

Don't remember a lot of things. Here we will help you sort out the Drupal configuration, which is nothing more than in files and databases. The configuration in the files is well handled, just upload them directly. What about the configuration that exists in the database? Very simple-first convert to a file and then upload the file.

Before providing examples of best practices for different configuration migration, we recommend that you remember the following figure: Code (configuration) from bottom up, database (content) from top to bottom-this is the basic rule of teamwork, so as to ensure that files and databases are deployed from new to old, reducing conflicts from the source.

(Many people ask this question during collaboration: "I modified the View configuration online and then updated the View configuration file offline. How can I update the View configuration file ?" This is a typical human conflict caused by nonstandard collaboration processes. Once the specification can constrain the update direction of files (configurations) and databases (content, this type of problem will basically not occur .)

Go back to the several questions mentioned at the beginning of the article. Now let's take a look at the configuration migration process suggestions:

Site configuration or other variable migration-use the Features module and pack the variables to be tracked in the file in conjunction with the Strongarm module, and then update and deploy them in the Dev-> Stage-> Prod direction.
Block configuration migration-use the Features module and the Features Extra module to package the block configurations and content into a file, and then update and deploy the block in the Dev-> Stage-> Prod direction.
Content type, field, view, input format, editor configuration, etc-use the Features module (if necessary, use Strongarm) to package the configuration into a file, then update and deploy in the Dev-> Stage-> Prod direction.
Content Data Update-use the Backup and Migrate module or other methods to export the online environment database, and update the content in the direction of Prod-> Stage-> Dev
 

Drupal configuration Migration Summary

Now, Drupal configuration migration is nothing more than two parts. Some of the content already exists in files (such as modules and themes), and you can directly upload files for updates; another part of the configuration (or content) that exists in the database, that is, the configuration is exported to the file through Features and other related modules, and then the file is updated.

Although Drupal configuration migration seems to have been written a lot, the main thing is to master the usage and process of the Features module. After a few exercises, you will find it very simple.