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

Question

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

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

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

Answer 1

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

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

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

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

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

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 и представлениями или node export, что позволяет вам экспортировать узлы, а затем импортировать их обратно в другую установку drupal.

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

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

Bonus точка (не относится к команде развития в частности):

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

Answer 2

Во-первых, лучшие практики.

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

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

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

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

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

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

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

Answer 3

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

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

Мне нравятся комнаты для разработчиков для распределенных проектов. Общение в реальном времени очень удобно. Некоторые элементы управления версиями могут записывать сообщения фиксации в чаты.

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

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

Answer 4

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