Как добавить контроль версий в мой рабочий процесс?


11

Я разрабатываю темы, их много. Мне дают PSD, кодируют HTML / CSS, помещают код в Wordpress и вносят исправления, когда они получают QC'd. Вживую клиенты могут редактировать сообщения в блоге, как обычно, или загружать фотографии с помощью специального плагина.

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

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

Требуются ли мне все изменения сайта на сервере разработки, а затем отправлять их после одобрения? Как насчет записи в блоге? Похоже, излишне писать посты на dev и публиковать изменения вживую, но как мне синхронизировать базы данных, если они редактируются на живом сайте? Я почесал интернет. Некоторое руководство будет оценено.


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

4
@ChipBennett Я не согласен. Приветствуются конкретные зависимости WordPress между темами, плагинами и базой данных, а также их влияние на общую практику разработчиков.
Fuxia

@ toscho Я, конечно, мог в этом убедиться; вот почему я указал на мета-обсуждение. :)
Чип Беннетт

Ответы:


9

Прежде всего, вы должны признать, что здесь есть два рабочих процесса: ваш и ваш клиент.

Ваш рабочий процесс

  • Получить PSD
  • Код HTML / CSS
  • Кодовый шаблон WordPress
  • Развернуть тему на живом сайте WordPress

Их рабочий процесс

  • Разработайте необходимые изменения и отправьте вам электронное письмо
  • Написать сообщения
  • Загрузить фотографии

Проблема

Реализация контроля версий здесь абсолютно не связана с рабочим процессом ваших клиентов. Все дело в отслеживании кода, который вы используете для темы WordPress. Все ваши файлы тем, пользовательские плагины и т. Д. Должны быть в системе управления версиями (Git, Mercurial, Subversion или как вы захотите использовать).

Ваш рабочий процесс становится:

  • Написать код
  • Внесите изменения в систему контроля версий
  • Нажмите изменения на производственной площадке
  • Получите комментарии от клиента
  • Написать код
  • Зафиксируйте изменения
  • Написать код
  • Зафиксируйте изменения
  • Нажмите изменения на производственной площадке

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

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

Код изменяет поток от разработки к производству.
Изменения базы данных передаются от производства к разработке.


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

@EAMann Отличный ответ, спасибо! Единственное, что я бы добавил к описанному вами рабочему процессу, - это написание кода, принятие изменений, отправка на сайт разработки, получение комментариев от клиента ... Я не рассматривал два отдельных рабочих процесса, потому что регулярно нам приходится менять довольствуемся клиентами. Иногда нам приходится помещать в контент HTML-код, чтобы учитывать особые запросы к контенту (специальные стили и т. Д.). Иногда они требуют одобрения клиента, прежде чем начать работу, поэтому базы данных должны быть синхронизированы. Есть ли лучшие практики для такого рода установки?
cfree

@Wyck Вместо того, чтобы отбрасывать контент вместе с темами, имеет смысл разделить два процесса. Мне нравится идея области разработки для создания тем и промежуточной области для размещения контента независимо друг от друга. Единственная проблема, которую я вижу, заключается в том, что клиентам нравится видеть как тему, так и контент (сайт целиком; статические страницы) до его запуска вживую.
cfree

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

3
Пока еще нет, действительно ли это проблема в WordPress, но не является проблемой WordPress, поскольку у многих CMS есть эта проблема, вы можете прочитать об этом здесь wordpress.stackexchange.com/questions/119/… более подробно, некоторые Сценарии существуют, но большинство из них находятся в доме, потому что они специфичны для определенной среды.
Wyck

1

Вы можете использовать программное обеспечение, которое синхронизирует базы данных. Но есть также возможность управления версиями самих данных с помощью чего-то вроде http://chronicdb.com


Это выглядит интересно; может решить немало вопросов. Я собираюсь проверить это, спасибо.
cfree

1

Я просто написал подробный ответ на этот вопрос по другому вопросу. Лично я использую git, и это фантастика. С точки зрения начала работы, я бы порекомендовал проверить http://gitref.org/ и http://help.github.com/mac-set-up-git/ . Если вы тип книги, я читал эту книгу, и она определенно стоит $ 22 за книгу. Заставь себя сделать это, ты не пожалеешь об этом решении.


Спасибо, я должен вернуться к этому. Настройка базы данных master / slave звучит интересно. Спасибо за руководство
cfree
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.