Git + Drupal рабочий процесс

Question

Я новичок в Git с вопросами рабочего процесса. Я выучил много команд, и я знаю, как все работает, но я не могу понять, какой правильный рабочий процесс. Люблю иметь несколько предложений. [Обратите внимание, я единственный разработчик, работающий над моими проектами]

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

2. Я использую одну и ту же базовую тему для всех своих сайтов на Drupal. Когда я делаю изменения в одном, мне нужно скопировать и вставить его примерно в 10 других местах. Есть ли способ сохранить эту базовую тему в одном месте и использовать другие сайты? Github может быть?

3. Если я хочу сделать «полную» резервную копию кодовой базы и базы данных - единственный способ сделать это - экспортировать базу данных в виде файла sql и зафиксировать все это?

Спасибо за помощь!

Терри

Answer 1

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

2. Вы должны использовать git pull вместо copy-paste. Поскольку git имеет децентрализованный дизайн, вам не нужно центральное расположение, такое как github. Если это полезно для вашего рабочего процесса, используйте его, но если нет, то вы можете получать данные напрямую с одного сервера на другой.

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

Answer 2

1. Я понимаю точку зрения вашего друга, но я категорически не согласен с выполнением (возможно, ошибочным, вероятно) некорректного кода разработки на рабочем сервере. Лучше загрузите VirtualBox и настройте виртуальную машину с той же конфигурацией, что и на сервере, на котором вы развертываете. Используйте git для создания «тегов» для каждой развернутой версии, чтобы у вас были полезные ориентиры для «версий» вашего веб-сайта.
2. Посмотрите на "git submodules". Вы почти наверняка должны узнать, что это такое, но если вы пришли из подрывной деятельности, вы, вероятно, найдете их очень запутанными. Подмодули в основном являются ссылками на другие репозитории, поэтому у вас есть мягкая ссылка на другой проект внутри вашего основного проекта. Однако они должны быть автономными в каталоге.
3. Лично мне нравится хранить файл schema.sql в моем хранилище (просто пустую схему, написанную на SQL), но я не думаю, что было бы разумно хранить полные резервные копии базы данных в хранилище, хотя вы можете. Храните их отдельно.

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

Одна твердая рекомендация: часто совершайте. Каждый раз, когда вы делаете изменения, которые работают, фиксируйте. Меньшие коммиты намного легче обрабатывать, чем большие. Например, если вам нужно отменить сломанное изменение, вы с большей вероятностью сможете отменить его, не удаляя кучу рабочего кода, который был зафиксирован в то же время, если ваши коммиты являются атомарными.

Answer 3

для сброса регулярных данных drupal db, которые я использую

а) псевдоним 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'

Answer 4

1. В общем, чем ближе ваши окружения друг к другу, тем лучше. Это становится особенно важным при попытке диагностировать и выследить проблемы. Дело не в том, что невозможно иметь разные настройки в каждой из ваших сред (dev, qa, prod и т. Д.), Но я бы, конечно, сказал, что желательно быть последовательным, если это возможно.

2. Настройка git-репозитория для общей темы - отличная идея для устранения проблем, унаследованных от копирования / вставки ваших изменений. Независимо от того, настроили ли вы git-репозиторий на своем собственном сервере или используете такой сервис, как github, это вопрос личных предпочтений.

3. Да, чтобы получить абсолютно все в резервной копии, вам нужно сделать sqldump базы данных в дополнение к хранилищу кода. При этом свободно используйте модуль Features и получите как можно больше своей конфигурации в коде. Это также помогает при перемещении между средами, а также позволяет отслеживать версии ваших изменений вместе с остальным кодом. Некоторые из наиболее важных элементов, добавляемых к вашим функциям: типы контента, представления, разрешения, переменные (через Strongarm ), размещение блоков (через Context ), меню и т. Д.