[support] Best practices for stage <--> productions

[Metzler, David]

You should really check out 

http://drupal.org/project/backup_migrate

There are lots of strategies out there, but I tend to follow the following strategy. 

* Set up identical but separate staging/development environments. 
* Do periodic clones from  production back to test/staging. 
* use the export import features that are provided with many key project (e.g. views, cck, panels) to move larger config changes to prod, and do the rest (tweaks) manually, first in test, then in prod. 

Many people would talk about using modules like features, etc to facilitate deployment, but I've found that most push config synchronization strategies create more work than they save. 

My 2 cents anyway. 

Also if you're a UNIX admin and new to the community.... you really need to get and install drush.  http://drupal.org/project/drush

Dave

-----Original Message-----
From: support-bounces at drupal.org [mailto:support-bounces at drupal.org] On Behalf Of Zyumbilev, Peter
Sent: Thursday, February 21, 2013 9:54 PM
To: support at drupal.org
Subject: [support] Best practices for stage <--> productions

Hi,

I have more than 10 years of web admin/dev experience but I am just
starting with drupal. I am about to set stage/dev environment for the
first project. Both production and stage are Unix(Freebsd), I have full
root access. What should be the best practices I should follow.

So far I found these:

(1) http://drupal.org/project/drush_ctex_bonus
(2) http://community.aegirproject.org/


What do you advise for best practices ? Nice to have, but not a must is
to be simple for the web developers e.g "press button sync": i.e they do
not need to contact for export, they do not need to go under ssh and use
git/svn.


Thanks,


Peter
-- 
[ Drupal support list | http://lists.drupal.org/ ]