Menu
Often after a Drupal (6.x) site is launched, I have people starting to sign up and enter their own content. Whenever there is need for an upgrade, the database on production is copied to dev and then the development is done on dev, later get pushed to staging for client's approval.
When the site is eventually ready to go live, there is a problem. Production server has the latest user inputted content, dev and staging have the latest functionality. Simply overwriting the database on production won't work. What I usually do is to write down what has been done to dev and than follow the steps to go though the implementations again on production. As the system grows bigger, one single mistake on production may cause lost of business. I can't shutdown the site for several hours. I can't tell how many people are using the site at a given time, even so it's impossible to wait for a time where nobody is on the site to make the upgrade.
Has anyone have any good idea?
Thanks in advance.
856
Drupal 7 community support is provided until November 2023 In light of the impact of COVID-19 on our community, Drupal 7 is supported until November 1, 2023. This means Drupal 7 will be supported throughout Drupal 9's life.
Run drush config:export in your Development site (older versions of Drush may use drush config-export instead) or just use the alias drush cex for short and it will work on all drush versions. This exports the configuration to your sync directory.
It allows you to divide up your configuration such that different situations or different environments may have vastly different configurations. Once configured, importing and exporting splits is done transparently with a recent version of Drush, or by using the config-split-export and config-split-import subcommands.
By default, Drupal places the configuration sync directory within the site's files directory, using a hash as part of the directory name, thus sites/default/files/config_HASH .
There are two concepts you need to look into: The first is "Exportables" which is generally a way of exporting all the configuration of a given module. The second is "Features" (terribly named, yes) which is a way of grouping a set of Exportables into a given changeset for version control, updating, deployment, rollback, etc.
For clarification, many modules implement their own "Exportables" methodology what I linked to above was the Exportables module. Here's a wider strategy for it - http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-your-drupal-module-ctools
122
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
