Мерзавец + рабочий процесс Drupal
Я - новичок Мерзавца с вопросами о рабочем процессе. Я изучил много команд, и я знаю, как вещи работают, но я, может казаться, не выясняю правильный рабочий процесс. Любовь, чтобы иметь некоторые предложения. [Отметьте, я - единственный разработчик, работающий над моими проектами]
Друг однажды сказал мне, что было лучше работать над живым сервером скорее это на localhost, чтобы не сталкиваться с конкретными вопросами среды. Это верное?
Я использую ту же основную тему для всех моих сайтов Drupal. Когда я вношу изменение в одном, я в настоящее время должен копировать и вставлять его приблизительно к 10 другим местам. Существует ли путь, сохраняют эту основную тему в одном месте и имеют другие сайты, тянут из него? GitHub, возможно?
Если я хочу сделать 'полное' резервное копирование кодовой базы и базы данных - единственный способ сделать, это должно экспортировать базу данных как sql файл и фиксировать все это?
Спасибо за справку!
Terry
3 ответа
В общем, вы должны запускать тестирование на сервере как можно ближе к производственному серверу, но не на самом активном сервере, так как это сломает работающий сайт во время тестирования. Поскольку Drupal разработан для работы на множестве серверов, использование похожих серверов не так актуально.
Вы должны использовать git pull вместо copy-paste. Поскольку git имеет децентрализованный дизайн, вам действительно не нужно центральное расположение, такое как github. Если это полезно для вашего рабочего процесса, используйте его, но если нет, вы можете напрямую перетягивать с одного сервера на другой.
Нет отличного решения для того, чтобы Drupal хранит так много информации о конфигурации в базе данных и синхронизирует ее. Один из подходов - синхронизация всей базы данных. Многие модули также имеют экспортируемые объекты, которые в основном сохраняют данные из базы данных в код, чтобы вы могли синхронизировать их вместе с остальным кодом. Возможности - это, вероятно, самый простой способ поэкспериментировать с экспортируемой моделью и посмотреть, работает ли она для вас.
- Я понимаю точку зрения вашего друга, но категорически не согласен с запуском (потенциально, ошибочно, возможно) неработающего кода разработки на рабочем сервере. Лучше скачайте VirtualBox и настройте виртуальную машину с той же конфигурацией, что и сервер, на котором вы развертываете. Используйте git для создания «тегов» для каждой развертываемой версии, чтобы иметь полезные ориентиры для «версий» вашего веб-сайта.
- Посмотрите на «подмодули git». Вам почти наверняка нужно узнать, что это такое, но если вы пришли из опыта подрывной деятельности, вы, вероятно, найдете их очень запутанными.Подмодули - это в основном ссылки на другие репозитории, поэтому у вас есть программная ссылка на другой проект внутри вашего основного проекта. Однако они должны быть автономными в каталоге.
- Лично мне нравится хранить файл schema.sql в моем репозитории (просто пустая схема, написанная на SQL), но я не думаю, что хранение полных резервных копий базы данных в репозитории было бы разумным решением, даже если вы можете. Держите их отдельно.
Если вы плохо знакомы с самой идеей систем контроля версий, вам, вероятно, лучше просто прыгнуть обеими ногами. По мере того, как вы идете, все обретет смысл. И, конечно же, по самой своей природе вы вряд ли нанесете какой-либо непоправимый урон, поскольку можете катиться вперед и назад.
Одна твердая рекомендация: совершайте часто. Каждый раз, когда вы вносите изменения, которые работают, фиксируйте. Меньшие коммиты намного проще обрабатывать, чем большие. Например, если вам нужно отменить неработающее изменение, у вас гораздо больше шансов отменить его, не удаляя кучу рабочего кода, который был зафиксирован одновременно, если ваши коммиты являются атомарными.
для сброса drupal db регулярно я использую
a) псевдоним git для создания пустой несвязанной ветки с именем "db" найдите псевдоним на http://gist.github.com/360294
б) следующие команды, используя отличные инструменты maatkit, чтобы очистить несколько неинтересных таблиц и сбросить базу данных в отдельные файлы, без комментариев
mk-find DBNAME --tbllike "cache%" --exec "TRUNCATE %D.%N";
mk-find DBNAME --tbllike "watchdog" --exec "TRUNCATE %D.%N";
git checkout db && \
cd /GITROOT/db && rm -rf * && \
mk-parallel-dump -d DBNAME -- mysqldump --skip-extended-insert --skip-comments --skip-lock-tables '%D' '%N' \> '%N.sql'