Каковы наилучшие практики для небольшой распределенной команды, которая будет работать над проектом Drupal?

ответ Джереми (+1) уже довольно полный. Некоторые дополнительные более практичные советы следуют в без определенного порядка.

отказ от ответственности: это то, что работает для меня. У других могут быть другие предложения или даже несогласие. Если это так, я был бы очень рад услышать отзывы и альтернативные/лучшие предложения!

1. сделать замечание, что каждый член команды должен начать его / ее сеанс путем обновления кода и базы данных. вы можете легко написать все это с помощью комбинации ssh и rsync команды. Я иногда создаю один скрипт (update-project.sh), который обновляет код из репозитория и загружает и импортирует последнюю БД с главного сервера сразу.

2. не забудьте позвонить http://example.com/update.php каждый раз, когда вы обновляете код. выполните эту команду на промежуточном сайте, после каждой фиксации и на локальном машина после каждого обновления / вытягивания / проверки.

3. сделайте любое изменение в БД через SQL-запрос, а не с помощью GUI. таким образом, вам просто нужно будет обернуть этот запрос в hook_update_N() реализация в вашем yourmodule.установить файл, и вы в целости и сохранности (если вы соблюдаете пункт #2!) [некоторые инструменты gui выводят эквивалент... это очень удобно!].

4. всякий раз, когда это возможно, включать в hook_update_N() также изменения в настройках модуля. это не возможно все время. Когда это невозможно: см. пункты 7 и 8.

5. при создании или изменении представления экспортируйте его в файл по завершении. тот же принцип, что и пункт №3, но применяется к представлениям. Этот подход, кстати, также имеет преимущество в обеспечении механизма отката в случае, если вы позже поймете, что совершили ошибку.

6. использовать a главный репозиторий. не слишком много распределенной системы управления версиями. Pull и push ваш код всегда из одного и того же Центрального РЕПО.

7. всегда включайте комментарий в фиксацию. особенно, если некоторые изменения кода изменяют некоторые функции / API / общую логику, обязательно включите предупреждение в сообщение фиксации. Подробную информацию можно поместить в журнал изменений.txt файл, если это необходимо.

8. при совершении, немедленно воспроизвести на главной БД любые сделанные вручную изменения БД, которые вам не удалось включить в свой hook_update_N() реализация. это необходимо, если члены вашей команды начинают свои сеансы, как описано в #1.

9. будьте избирательны в том, что вы ставите под управление версиями. например: исключить sites/default/settings.php но оцените, что (если что-нибудь вообще) нужно быть версионным из in sites/default/files (нужны ли изображения для разработки? и вложения?).

10. есть некоторые полезные модули, которые могут помочь. как импорт/экспорт, что позволяет вам управлять в репозитории вашими CCK и представлениями или экспорт узле это позволяет экспортировать узлы, а затем импортировать их обратно в другую установку drupal.

11. использовать модуль simpletest широко. что это хороший идея в любом случае, но при работе в команде большой идея: таким образом, вы будете уверены, что ваши изменения не нарушили чью-либо работу.

12. удачи! я люблю работать в команде, и я считаю, надо стараться делать это каждый раз, когда он/она может. Это больше удовольствия, больше обучения и прежде всего... лучший код! :)

бонусный балл (не относится к разработке команды конкретно):

• попробовать не использовать промежуточный сервер для вставки реального содержимого. в идеале вы должны начать создавать контент только тогда, когда код каким-то образом зависает или использует импортную маршрутизацию/модуль: drupal рассеивает информацию по таблицам много, и система крючков очень затрудняет отслеживание, какие модули сохранили какую информацию где: если вы разрабатываете на БД с реальными данными, вы неизбежно в конечном итоге нарушите некоторые таблицы в какой-то момент, и вы можете понять, что только за день до производство. :(