Git, Beanstalk, WordPress Ultimate Deployment Approach

Question

Я использую Git и Beanstalk для разработки WordPress локально, а затем развертывания на производственном сервере с помощью процесса развертывания Beanstalk. Но как мне синхронизировать изменения, сделанные на производственном сервере, с моей локальной репутацией development/git? Изменения на сервере произойдут в любое время, когда кто-то установит плагин. Есть ли способ вернуть эти изменения в локальные?

Я ценю любую помощь с пониманием начинающего. Благодаря!

Answer 1

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

Я устанавливаю гитолит как наш удаленный репозиторий. Это круто.

Наша ветвление модель работает как так, с WordPress в качестве контекста:

master - # this is the _vanilla_ install of wordpress with no modifications 
prod - # the branch that the production server pushes/pulls to 
dev - # dev environment pushes/pulls to, in our case a server 
alpha - # really early development, ideas, etc - my personal branch that i work on mostly 
features (opt) - # as needed, I'll make feature branches then merge them into the other branches. 

Наша прод, который обрабатывает около 40-45 различных статических файлов в день, имеет хрон, который автоматически добавляет/обязывает пользователя изменен файлов и данных на ежедневной основе. Это забирает все пользовательские изменения и будет (в вашем случае) забирать установки плагинов. Это здорово, потому что у вас есть история об их установках.

Фактические изменения в кодовой базе обычно изучаются в альфа, а затем объединены до dev. Мы создали несколько перехватчиков, где, когда мы push в ветвь dev, dev-сервер автоматически pulls новый фиксатор в. Затем они синхронизируются.

После того, как он был протестирован в среде разработки, я синхронизирую свою локальную производственную ветку с пультом дистанционного управления, которая, как указано, ежедневно получает пользовательский контент. Затем я буду merge или cherry-pick совершить в продукт, затем push, чтобы получить на гитолите. После этого сервер prod pulls и все счастливы.

Это звучит как много работы, но на самом деле это очень эффективно, особенно после некоторых скриптов на крючке. Я все еще в процессе настройки нашего развертывания (например, я почти полностью избавляюсь от ветки alpha и работаю с dev/feature локально), но мы получаем потрясающий бонус, фактически имея ежедневные снимки производственного сервера, и возможность синхронизации всех ветвей в любое время.

Кроме того, в отношении вашей ветви master - оставляя это как установку ванили для WordPress, это потрясающе, потому что вы можете легко протестировать обновления новой версии. Вы можете просто проверить мастер, затем запустить обновление и медленно интегрировать настройки.

Answer 2

Изменения, в идеале, не должны производиться, по моему мнению. Не можете ли вы взглянуть на способ установки плагинов, посредством которого вы добавляете плагин в git repo и подталкиваете его к prod? Я понимаю, что вы, вероятно, говорите об установке плагина из пользовательского интерфейса WordPress, который добавляет его в PROD, но я чувствую, что вы должны получить содержимое плагина, добавить свое репо и нажать PROD.

Если это невозможно вообще, вы должны убедиться, что контент плагина зафиксирован, когда в PROD установлен новый плагин, а затем вы можете установить git pull контент для синхронизации.

Answer 3

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

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

Недостаточно удаления всех приятных функций в Wordpress, которые позволяют пользователям делать то, что кодеры считают плохими, должно быть решение для этого. Я использую beanstalk, и мне было бы очень приятно, если бы помимо развертывания на производственном сервере я мог бы сказать, что он автоматически добавляет изменения с производственного сервера обратно в репо и уведомляет меня об изменениях. Тогда я мог бы пойти и разложить все, что происходит, и если его проблема передислоцируется из предыдущей версии.

Как есть, ситуация ограничена и требует больше работы. Полагаю, я мог бы попытаться построить собственный механизм автоматического вытягивания и проверки, но это звучит утомительно. Если кто-то знает лучший способ (помимо запуска серверов с SSH), мне было бы интересно услышать решение.