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
FAQ: http://drupal.org/best-practices Earnie On Fri, Feb 22, 2013 at 12:54 AM, Zyumbilev, Peter <peter@aboutsupport.com> wrote:
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/ ]
-- Earnie -- https://sites.google.com/site/earnieboyd
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Zyumbilev, Peter Sent: Thursday, February 21, 2013 9:54 PM To: support@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/ ]
Welcome to Drupal! I would strongly suggest using the features module http://drupal.org/project/features as a means to pack DB changes together into deliverable chunks that you can then install on your staging server (and eventually production server) for doing test-deployments. Features for the DB and GIT/Mercurial for the code-base = version control and (nearly) full coverage for the database changes you need to track across platforms. Features will require other modules to get full use, like Strong Arm for some parameters, but once you dig into it you'll figure out what it is you might need to add to the mix. Good luck! datarazor On Friday, February 22, 2013 at 8:35 AM, Metzler, David wrote:
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Zyumbilev, Peter Sent: Thursday, February 21, 2013 9:54 PM To: support@drupal.org (mailto:support@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/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
David when you say clones do you mean working with git? In our online study group at http://drupalistasgroup.com/ we have been exploring multi-sites and backup and migration strategies. As you said there are lots of strategies. Anyone is welcome to join us. Tony On Fri, Feb 22, 2013 at 8:35 AM, Metzler, David <metzlerd@evergreen.edu>wrote:
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Zyumbilev, Peter Sent: Thursday, February 21, 2013 9:54 PM To: support@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/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
-- *Anthony Stefan Maciejowski* *www.Tony-Mac.com*
No I do not. I use git for code and only code. Much of configuration (views content types,etc) for drupal is stored within the mysql database. The database is not something that plays well with version control. (You don't want git to have the "Data" e.g. specific Articles and such in the DB but you might want the configuration) . The backup/migrate module facilitates complete copies of the database from production back to staging/devel. It does not require Git access to do. In Drupal 8 we'll be excited to see much of this configuration information being able to be stored in the filesystem which is far more version controllable. Then you'll be able to choose configuration trees that could be managed with version control, but until then configuration is hopelessly mingled with content, and the line between them is both grey and subjective. If you're planning on using git to track configuration (not source code) then I'd encourage you to look at features as others have suggested. It will take more to ramp up on than backup/migrate, but I was under the impression that you wanted to avoid having your site admins do that. Much depends on what kind of shop you are and what fits best with your current practices. Dave ________________________________ From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Anthony Sent: Friday, February 22, 2013 10:54 AM To: support@drupal.org Subject: Re: [support] Best practices for stage <--> productions David when you say clones do you mean working with git? In our online study group at http://drupalistasgroup.com/ we have been exploring multi-sites and backup and migration strategies. As you said there are lots of strategies. Anyone is welcome to join us. Tony On Fri, Feb 22, 2013 at 8:35 AM, Metzler, David <metzlerd@evergreen.edu<mailto:metzlerd@evergreen.edu>> wrote: 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@drupal.org<mailto:support-bounces@drupal.org> [mailto:support-bounces@drupal.org<mailto:support-bounces@drupal.org>] On Behalf Of Zyumbilev, Peter Sent: Thursday, February 21, 2013 9:54 PM To: support@drupal.org<mailto:support@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/ ] -- [ Drupal support list | http://lists.drupal.org/ ] -- Anthony Stefan Maciejowski www.Tony-Mac.com<http://www.Tony-Mac.com>
To be blunt this is an area that Drupal has some issues with because of how how content and configuration are stored. Great strides are being made in the Drupal 8 release and there are ways to build solutions now that will meet your needs. There are methods for moving content from a staging environment to production There is a lot of working happening around the UUID Module http://drupal.org/project/uuid. The Features module is a great ways to export configuration along with the Strongarm Module (http://drupal.org/project/strongarm) . Using GIT helps to manage code but there are systems out there. Welcome to Drupal and I hope this helps. -Steve On Feb 22, 2013 9:35 AM, "Metzler, David" <metzlerd@evergreen.edu> wrote:
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Zyumbilev, Peter Sent: Thursday, February 21, 2013 9:54 PM To: support@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/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
participants (6)
-
Anthony -
Earnie Boyd -
Info Razor -
Metzler, David -
Steve Kessler -
Zyumbilev, Peter