ExpressionEngine: git: локальная разработка: удаленная база данных

Для тех из вас, кто пытается быть хорошим небольшим разработчиком и версией, контролирует свои сайты ExpressionEngine с помощью git, как вы обрабатываете свою базу данных?

В моем ограниченном опыте работы с несколькими разработчиками, работающими на одном сайте ExpressionEngine, нам приходилось все убегать от одной базы данных разработки MySQL, работающей на удаленном веб-сервере. Для тех из вас, кто пробовал это, он БОЛЬШОЙ медленный. Загрузка страницы может занять 5-10 секунд, что затрудняет разработку. Быстрее работать с сервером удаленного развития. Я стараюсь избегать отработки удаленного сервера MySQL, чтобы работать в любом месте и не зависит от скорости/качества интернет-соединения.

Просто интересно, как другие обрабатывают свои базы данных MySQL.

У всех ваших разработчиков заканчивается одна центральная база данных? Были ли у вас проблемы с медлительностью, как у нас?

Сохраняете ли вы свою базу данных под контролем версий? Как вы обрабатываете экспорт/импорт между несколькими разработчиками и несколькими ветвями?

С одним разработчиком я могу легко импортировать/экспортировать/скопировать базу данных, но как только вы добавите еще одного разработчика в микс, он становится очень ОЧЕНЬ грязным. С нетерпением ждем всех мыслей по этой мамонтовой теме.

Спасибо!

Ответ 1

Вы недавно просмотрели EE Profiler? Вероятно, вы заметите в окрестности 20-80 запросов на своей домашней странице в зависимости от сложности.

Проблема заключается в том, что для каждого запроса MySQL должен выполнить удаленный запрос данных, загрузить ответ, а затем представить ExpressionEngine его данные. 20-80 круглых поездок в базу данных - вот что заставляет вас задерживаться, и я не думаю, что вы можете с этим справиться. При использовании удаленной (вне нашей сети) базы данных я получаю ту же задержку, что и вы.

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

Что касается исправлений, все, что вы можете сделать, это перейти к базе данных, размещенной в вашей внутренней сети. У нас есть машина Linux, которая имитирует нашу производственную среду, которую мы используем для постановки. Поскольку в нашей сети мы можем использовать локальный IP-адрес в нашем database.php файле. Это намного быстрее.

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

Ответ 2

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

Запустите сервер MySQL с помощью start mysqld with --skip-name-resolve. (Более подробную информацию по этой теме можно найти здесь: http://dev.mysql.com/doc/refman/5.0/en/host-cache.html)

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

Ответ 3

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

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

Что касается контроля версий, я сохраняю копию моего базового EE файла установки SQL в моем базовом репозитории. Помимо этого я обычно не сохраняю копии базы данных в Git, поэтому я не занимаюсь импортом/экспортом и т.д.

Ответ 4

В моей компании (4 разработчика) каждый из нас запускает собственную БД локально. Но в последнее время я тестировал базы данных Rackspace Cloud (но есть другие поставщики облачных db) для тяжелой БД, которая может стать трудной для запуска на маленьком ноутбуке. Это относительно дешевле, чем запуск нашего собственного сервера db, и его можно настроить или удалить за минуту.