Каковы лучшие практики для небольшой распределенной команды, которая будет работать над проектом Drupal? - PullRequest
7 голосов
/ 30 ноября 2009

после некоторых исследований мы решили работать с Drupal над нашим следующим проектом, и мы являемся распределенной командой.

Поскольку Drupal хранит (основываясь на том, что мы видели до сих пор) весь свой контент в базе данных, как мы, как распределенная команда, можем работать вместе над этим проектом? Какие лучшие практики мы должны принять?

Мы подумали об использовании общего сервера базы данных для этой задачи, но это могло бы просто снизить производительность, которая нам необходима для запуска этого проекта. Есть предложения по этому поводу?

Ответы [ 4 ]

7 голосов
/ 30 ноября 2009

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

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

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

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

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

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

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

  6. Используйте главный репозиторий. Не используйте слишком много распределенной системы управления версиями. Тяните и нажимайте свой код всегда из одного и того же центрального репо.

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

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

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

  10. Есть несколько полезных дополнительных модулей, которые могут помочь. Как и import / export , который позволяет вам управлять в хранилище CCK и Views или узлом экспорт , который позволяет экспортировать узлы и затем импортировать их обратно в другую установку drupal.

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

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

Бонусное очко (не относится конкретно к развитию команды):

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

Прежде всего, лучшие практики.

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

Вы должны использовать систему контроля версий, чтобы делиться своим кодом, чтобы вы все работали с одной и той же кодовой базой, но имели контроль над тем, когда объединять код.

Совместное использование базы данных разработчиками или совместное использование кодовой базы разработчиками может привести к путанице, и ее следует избегать.

Теперь еще несколько мыслей, основанных на мнении

Контент для вашего сайта должен создаваться и редактироваться на реальном сервере.

Вы должны выпускать код управляемым, повторяемым способом. В идеале у вас должен быть промежуточный сервер для проверки кода перед его началом.

Сложная часть - это изменения содержимого и конфигурации. Я выступал за то, чтобы это было сделано в функциях обновления в фиктивном модуле. Однако иногда это трудно сделать, а в некоторых случаях изменения не могут быть сделаны надежно. Таким образом, должен быть баланс, большинство изменений конфигурации должно быть сделано в коде, чтобы они были повторяемыми и могли легко распространяться среди разработчиков. Но для изменений конфигурации, которые нелегко закодировать или которые требуются вне окна выпуска, вы можете сделать их непосредственно на работающем сервере. Важно то, что вы можете привести свой код и базу данных в согласованное состояние в процессе разработки и в режиме реального времени.

1 голос
/ 02 декабря 2009

Simpletest - бесценный инструмент, так как разработчик, работающий над модулем «A», может запустить набор тестов и убедиться, что он / она не сломал модуль «B», а затем зафиксировать (например). Смотрите модуль Simpletest и Selenium IDE. Разработка через тестирование окупается многими способами. Разработчики обретают уверенность и могут работать быстрее / лучше.

Некоторое хорошее программное обеспечение для отслеживания проблем и / или управления проектами может сохранять централизованную информацию о проекте и облегчать взаимодействие между разработчиками. Вики тоже хороша. Электронная почта между менеджерами проектов и отдельными разработчиками не держит всех в курсе и может затеряться во времени в шумной среде электронной почты.

Мне нравятся чаты разработчиков для распределенных проектов. Беседа в режиме реального времени очень удобна. Некоторые системы контроля версий могут записывать сообщения коммитов в чаты.

Модуль backup_migrate удобен для получения последней версии фиксации БД с рабочего сервера. Конечно, вы можете экспортировать через mysqldump и т. Д., Но этот маленький модуль не составляет труда.

Проверьте также и кислород. Заставьте своих разработчиков писать в этот формат. И обратите внимание на стандарты кодирования drupal. Есть модуль под названием «кодер», который может это проверить.

0 голосов
/ 03 июля 2013

Я вижу, что это СТАРЫЙ пост в отношении управления конфигурацией Drupal. На данный момент, в 2013 году, я определенно рекомендую использовать полный набор функций. Это позволяет вам размещать конфигурацию в коде и использовать контроль версий (я рекомендую git) для передачи файлов через вашу среду. Есть несколько предостережений, но это работает по большей части. Для предостережений, использование советов, упомянутых в принятом ответе, поможет смягчить путаницу

...