By Passero on
Suppose you have 3 environments:
1 for development
1 for testing
1 for production
If you changed the site on devevelopment and want to move it to test so users can test before it goes to production. What is the easiest way to do this?
A complete export/import from one environment is not possible because the content on those system will be different. You can not import the testdata on a production...
It's also strange that the configuration you do on new or existing modules, you should do them on each environment i guess...
Is their a way so you can export/import only the things you need or how should i move from one to another?
Comments
Have you had a look at the
Have you had a look at the backup modules?
http://drupal.org/project/modules?text=backup
Personally, I use 'backup and migrate' for the database, and for the time being I just ftp the files directory and all it's subdirectories between the sites. I plan on checking out the 'backup and migrate files' extension, but have not yet.
When it's a major change to the site, I test with a multisite setup, giving the new version a subdomain, testing new modules in that site alone. When it's ready, its pretty easy to switch the multisite setup so the new version is the main, and the old current is kept for a bit just in case. However, you'll have to take the current site down for a clean transition.
If doing a drupal security upgrade, such as 6.13 to 6.14, then I setup the new site in a separate subdirectory, and use the .htaccess to switch from one version to the next.
However, re-reading your post, it sounds like you're creating content dependent logic, and are concerned about being unable to move dev to test to live... First you need to make your environments portable, and that's with a configuration file, db tables, .ini files or whatever you choose. But get your environment so you can copy it from a to b and then with an update of the config run it in b. Then, when dev has a new release, that gets pushed (copied) to test. If there's a data incompatibility, then that's a production problem you have to solve. (Have a look at how Drupal handles module updates.) I would expect there's an effort to get dev and test synchronized to a 'release' state, and then that gets pushed to live. Its really just a matter of organization; no matter what you're building, you can organize it for development and portability.
-Blake
www.BlakeSenftner.com www.3D-Avatar-Store.com
this is an age-old problem,
this is an age-old problem, since so many of Drupal's configuration settings are stored in the database and can't easily be tracked in a revision control system.
my approach -- tedious and error-prone -- is to track a manual list of configuration settings in my repository along with the code.
many folks have discussed ways of storing config settings as code in your repo, though the potential problems there seem to outweigh the benefits for most of my cases.
there are also efforts being made to facilitate this via contrib modules. see modules like deploy and features for ideas.
but i haven't dug too deep in a while! can anyone else comment on whether the community seems to be converging on a better solution for this?