Нет времени, чтобы написать полный ответ (я знаю, что это глупо), но, вероятно, стоит поделиться им в любом случае (я мог бы отредактировать это, потому что я также планирую пост в блоге):
Это означает, что у вас может быть некоторая настройка WP на основе ствола / версии ветки, которую вы можете полностью взломать вкл. темы и плагины.
Поскольку это один независимый (локальный) репозиторий, вы можете отправить его через ssh в другие репозитории, например, в один:
- Он находится на удаленном хосте, на котором должен быть развернут сайт (голое хранилище).
- У него есть хуки, позволяющие другому хранилищу на этом хосте слиться с изменениями, которые вы только что добавили.
Это обрисовано в общих чертах в веб-рабочем процессе Git (ноябрь 2008 г .; Джо Маллер) .
Если у вас есть переключатель конфигурации, который выбирает конкретный wp-config.phpвариант на основе системы, на которой он работает, вы даже можете централизованно настроить все хосты (разработка, live, staging, friends, ...) внутри репо.
Восходящие изменения в WP вы просто извлекаете и объединяете в поддерево.
Плагины вы просто обновляете и фиксируете.
Развертывание простое $ git push remote.
Выполняйте ежедневные резервные копии на удаленном хосте для git-репозиториев, базы данных и загруженных файлов, и это дешево, удобно для разработчиков и гибко. Это хорошо работает как для разработчиков с одним разработчиком, так и для небольших команд, потому что каждый может получить извлечение из простого репродукции на удаленном компьютере.
Есть несколько предостережений:
Теперь с вашим контрольным списком и настройкой, как описано выше:
1. Хотелось бы, чтобы моя среда git находилась на моем собственном сервере, не используя Github для работы с репозиториями.
Здесь Github работает только с репозиториями верхнего уровня (Wordpress), а не с вашим собственным.
2. Автоматическое создание поддоменов при создании git-ветки (development.domain.com, ryan.development.domain.com). Возможно, для этого подойдет некоторый обработчик сценариев оболочки.
Установка, как обрисовано в общих чертах, является модульным подходом с одним репо на сайт. Он может обрабатывать столько хостов разработки, сколько вам нужно, он может одинаково хорошо работать с многосайтовой установкой для обработки нескольких доменов, но в этом подходе это считается одной установкой wordpress.
3. Phing PHP / Shell скрипт. Обработка переноса db (что-то вроде этого http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ) для обработки замены сериализованной базы данных при нажатии
В этом нет необходимости, так как только код находится под контролем версий, базы данных независимы между разработкой (подготовкой) и производством, как и должно быть.
Возможно, вы ищете сценарий установки, который выполняет миграцию домена правильно, но даже с более качественным кодом (который доступен), имеющим дело с поиском и заменой сериализованных данных, в этой настройке здесь обычно нет необходимости, так как вы просто вносите изменения в жизнь для тестовых случаев вы можете быстро создать контент в базе данных разработки, что, как правило, является наименьшей проблемой (из моего практического опыта ваша может отличаться, но я бы также предложил оставить такие темы, связанные с миграцией базы данных, по вопросам собственные здесь на сайте - но, пожалуйста, спросите их).
Я запускаю около 200 сайтов на своем собственном сервере и хотел бы приступить к внедрению этих сайтов в мощную рабочую среду Git, чтобы я мог значительно упростить свою работу.
Я не могу себе представить, как эти сайты стали бы в среде рабочих процессов строки git. Возможно, скрипты конфигурации и данные конфигурации, которыми вы управляете, будут находиться под контролем git-версии. Это может иметь смысл. Иначе, из-за огромного количества сайтов, я думаю, что нет никакого смысла держать всех в одном git-репо. Возможно, даже не один из них, потому что то, что я изложил выше, предназначено для сайтов, которые вы разрабатываете (включая код ядра WP), а не только для задач установки. Поэтому вам, вероятно, нужно сначала создать небольшую карту этих 200 сайтов и узнать, как они взаимодействуют друг с другом и из каких пакетов (WP core, Plugins, Themes) эти сайты состоят. Первым делом может быть создание электронной таблицы / матрицы и размещение всех сайтов.
Затем вы можете сохранить его как CSV, поставить его под контроль версий и заставить сценарии развертывания выполнять свою работу на основе этого файла.
И если я чему-то научился с помощью автоматизации задач: следуйте философии Unix, используйте существующие и хорошо работающие инструменты (лучше потратить полдня на чтение некоторых команд, а затем пытаться искать альтернативы, потому что для большинства рабочих мест проблемы были уже решено) и сосредоточиться на инструментах командной строки. Они самые мощные.