2

We're looking to manage our install of Drupal 7 with CVS (sadly Git and SVN are out). Do you have any pointer for things to think about when setting up the repositories?

Our lay of the land is as follows:

  • Our staff include UI developers, back-end developers , administrators, and DBAs.
  • For starting, we're going to install various modules (e.g. Domain, LDAP, Workflow, and Views). We'll write some custom modules down the road. We're also looking for implementing our own look and feel.
  • We have Dev, Test/QA, and Production instances of Drupal. The flow of code and configurations will be from Dev to Test/QA to Production (with some looping between Dev and Test).
  • We'll have top level domains and several subdomains.
  • We're on RedHat Enterprise Linux 5.5, MySQL 5.x and Apache 2.x.

What are the ways of managing changes that have worked for you?

Improve this question

1 Answer 1

Reset to default
6

Regardless the used VCS, here is what I put in my code repository

  • A .make file used to download Drupal core, contrib modules and contrib themes and apply patches (if required)
  • a module folder with only the custom modules
  • a themes folder with only the custom themes
  • A build script to
    • run drush make on the .make file to download Drupal core and contribs to a (VCS ignored) dist folder
    • copy the modules folder to dist/sites/all/modules/custom
    • copy the themes folder to to dist/sites/all/themes/custom

This to

  • properly track changes to the custom code
  • properly track used core and contribs versions (in the .make file)
  • prevent core or contribs hack
  • allow proper patching (Drush Make requires the applied patches to be on publicly accessible)

For the build script, I use Phing but any scripting languages (ant, bash, php, ruby, etc.) could be used. With some additional work, the build script can also be used to run automated test (SimpleTest) and code validation (php -l and Coder Review).

I try to have as much configuration as possible exported into code. Mainly by using exportables through the Features module and by having a project specific profile to define and update non-exportable configurations through its hook_install and hook_update_N implementations. See The Development -> Staging -> Production Workflow Problem in Drupal and the Code driven development: using Features effectively in Drupal 6 and 7 presentation.

Improve this answer
0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.