Должен ли я контролировать источники модули в моем проекте?

Мне сказали, что при разработке я должен контролировать исходный sites/код в своем хранилище кода (например, SVN).

Предполагая, что я никогда не коснусь ни одного из модулей contrib, которые я использую ( ctoolsи viewsт. Д.), А создам только свою собственную тему, должен ли я это делать?

Или я должен просто контролировать все под sites/all/themes/?

Спасибо

— cherouvim
источник

Ответы:

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

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

Если вы абсолютно не можете использовать команду drush и drush make, я не понимаю, почему нужно использовать код контроля версий, который имеет хорошую версию в другом месте. И если вы намереваетесь взломать один из модулей, то вам следует добавить это как подмодуль , опять же, не версионируя код в вашем собственном репо. (Я считаю, что это называется ветвью поставщика в SVN).

Изменить: Для получения более подробной информации и более сложных настроек, вы можете взглянуть на этот репозиторий: git@github.com: letharion / Drupal-build-scripts.git Скрипты написаны на bash для поддержки рабочего процесса моей команды, который включает в себя здание профиль базовой установки ( NodeStream ), а затем наш специфичный для сайта профиль, файл make для каждого профиля, хуки для применения исправлений или внесения других изменений на отдельных этапах сборки и т. д. Я надеюсь, что найду время для повторного - напиши это как расширение в ближайшем будущем.

— Letharion
источник

Спасибо за ваше подробное объяснение. Да, я использую drush и планирую максимально автоматизировать. И я не планирую изменять какой-либо код в основных или дополнительных модулях.

— Черувим

+1 создание версии файла make - отличная идея, думаю, я сделаю это в будущем;)

— Клайв

@Letharion Я не совсем понимаю, как это работает при разработке одного и того же сайта с разными разработчиками одновременно? AFAIK drush make всегда загружает все зависимости и пытается перезаписать сайты / default, даже если эти модули уже были D / L, или есть какая-то недокументированная опция для загрузки только обновленных / новых модулей? Другими словами: я понимаю преимущества использования Drush make для повторной установки, но как вы используете его для синхронизации модулей в распределенной команде?

— Крейндерс

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

— Дэвид Майстер

В противовес ответу @ Letharion, размещение всего в SVN имеет смысл для некоторых организаций, и это действительно зависит от того, как вы выполняете развертывание. Поместить модули и темы contrib в SVN может иметь смысл, если вам когда-нибудь понадобится вернуться в прошлое и взглянуть на старую версию сайта.

Один из примеров этого удобен, когда вы подозреваете ошибку в модуле contrib или наблюдаете другое поведение. Способность восстановить полную версию из прошлого может помочь.

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

— mpdonadio
источник

Чтобы вернуться «в прошлое», мне также понадобится соответствующая полная резервная копия базы данных. Потому что некоторые настройки и конфигурации находятся в БД. Это правильно?

— Черувим

Да. Модуль Backup and Migrate и / или drush архив-резервная копия - ваш друг здесь.

— mpdonadio

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

— Keithm