Drupal和版本控制

Question

I looked for similar questions to mine and one seemed promising, but the accepted anser was not applicable to me (I think.)

Drupal Source Control Strategy?

Basically one has to have rights on the server you are deploying to. That is not my situation. I use a hosting service and I do not think I can install SVN on it.

So, do i just develop on a "dummy" site and somehow do a lots of juggling by testing ont eh dummy site, getting the content (Including the database) and putting that in SVN and then releasing it to my live site?

What does the Drupal database look like? My dummy and live sites wo not/will not have the same admin/user logins, etc.

What are others doing for developing in Drupal and managing revisions?

Answer 1

Quite a few hosting services -- even cheap shared hosts -- have the SVN or CVS client installed. That's different than SVN hosting , a service that some hosting companies do explicitly offer. It's worth checking; having a source control client will make your life a lot easier no matter what.

Our launch workflow tends to go something like:

• Set up the codebase
• Put it into SVN/git/whatever Develop, code, create content, configure, etc
• Make DB snapshots at regular intervals to preserve sanity
• Delete any dummy content or dummy user accounts that were created during development
• Push code to a production or test box
  • If you have a source control client on your host, use it to deploy the codebase.
  • If you don't, make an explicit branch or tagged version of your codebase using whatever mechanism your source control system of choice offers.
  • Don't change code on the live server. Always use source control update, or upload a full copy of the "blessed" branch/tag. Getting the live site's code out of sync with itself is hell.
• If you need to push a new snapshot up and online, either have a separate /db directory out of the webroot that is also under source control, or just use SFT and upload the DB snapshots on an adhoc basis. You don't want to keep them in a web-accessible directory obviously, as people downloaing your raw DB snapshots is double-plus-ungood.

I did a presentation on deployment stuff a month or so ago and posted the slides online; it might be useful. slideshare link

Answer 2

There are two aspects of versioning with Drupal.

1/ Structure

GIT is my weapon of choice, it's largely adopted in the Drupal community, outside too actually, and extremely flexible.

With Drupal , you then need a couple of essential tools.

• Features , a module which will help you put to code some of your sites structure that usually reside in the database. Views, Content Types, Taxonomies Vocabularies, even Taxonomies Terms, if you use the UUID & UUID Features modules, etc...
  

• Drush not only will help you with creating & updating your features but it's an essential tool to have when building Drupal sites. Unless you're allergic to the command line, managing Features with Drush is far more flexible & robust than using Features' UI.
  
  

2/ Content

That's one is even simpler , provided you don't have a large amount of content, you can use the Backup & Migrate module.

Some Drupal friendly hosting services will provide you with GIT preinstalled, if you really can't have access to a server, GIT still remains an excellent development tool.

Sorry, I haven't provided any links, it's bit late here but these tools are very easy to find, I'm sure you'll have no problems whatsoever!