Как загрузить существующий сайт на github?

Question

[Alek Ivanov]

Есть тестовый сайт на wp.
Хочу для себя записывать изменения на сайте.
Есть какой-то плагин для синхронизации изменений или как загрузить на github чтобы можно было создать обновленную версию с изменениями.
Спасибо

Comments

[Дмитрий]

только стоит учитывать, что так будет трэкаться только код
все правке в базе сохраняться не будут

Answer 1

[Rickkk]

Плагин не посоветую.
Если плохо значете git, но хотите заливать код на github - воспользуйтесь gitkraken. Подключите его к своей учетке на github. Его интерфейс достаточно прост.

Comments

[Alek Ivanov]

попробую спасибо

Answer 2

[Сергей П]

WP - это CMS.
Она хранит контент в БД.
Что вы называете "изменениями"?
Если речь о контенте, то вам не нужно его размещать в системе контроля версий (github).
Кроме контента у сайта на WP есть конфигурация. Часть конфигурации, насколько я понимаю, находится в БД, а часть может быть вынесена в файлы настроек.
Эти файлы имеет смысл выносить в git.
Ваш сайт - это, в идеале, несколько docker-контейнеров:

1. контейнер с wordpress
   
2. контейнер с БД
   
3. контейнер с nginx, чтобы отдавать статику и роутить несколько отдельных кусков сайта. например вы подключаете отдельную галерею или что-то еще.
   

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

На докер-хабе есть готовый стандартный контейнер с вордпрессом. Идеально его не модифицировать вообще. Но вордпресс как-то там сам любит обновляться. Не знаю как конкретно с ним это лучше делать.
Прелесть контейнеризации в том, что для бэкапа сайта нужно по факту забэкапить только БД и несколько пару докер-файлов, докер-компоуз и горсточку конфигов. Можно еще полодить в репозиторий архив с дизайном.
Делается это с помощью обычной команды git. Полно с татей как с ним работать.
Конкретные вопросы есть?

Comments

[Игорь Воротнёв]

Кроме контента у сайта на WP есть конфигурация. Часть конфигурации, насколько я понимаю, находится в БД, а часть может быть вынесена в файлы настроек.
Эти файлы имеет смысл выносить в git.

Часть конфига категорически нельзя выносить в git. Например - соли, логин-пароль для доступа в базу. Вообще, в идеале принято либо не добавлять wp-config.php в git, либо выносить sensitive данные в отдельный подключаемый конфиг и не вносить только его, либо вообще выносить значения в .env файл.

Ваш сайт - это, в идеале, несколько docker-контейнеров:

Да что ж все так носятся с этим докером. Это совершенно ненужная прослойка. Есть решения значительно проще и понятнее.

Рендер делают в отдельном контейнере, иногда на отдельной машине.

шта?? Зачем? Какой такой рендер? Вы реально усложняете простые вещи.

Прелесть контейнеризации в том, что для бэкапа сайта нужно по факту забэкапить только БД и несколько пару докер-файлов, докер-компоуз и горсточку конфигов.

Для переноса / бекапа сайта надо:
- база (дамп)
- свой кастомный код (должно быть под гитом)
- сторонний код (сам WP, плагины и тд - в идеале должно устанавливаться/разворачиваться автоматом)
- медиа-файлы и прочий user generated content
- кастомный код, используемый только локально (конфиг или .env, плагины для dev-среды онли)

[Сергей П]

Часть конфига категорически нельзя выносить в git.

Игорь Воротнёв, это само собой. Забыл упомянуть.

Да что ж все так носятся с этим докером. Это совершенно ненужная прослойка.

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

Есть решения значительно проще и понятнее.

Есть и их достаточно много, но универсальных мало. На счет "проще и понятнее" - это тоже лукавство. Проще и понятнее кому? Веб-мастеру с пятнадцатилетним стажем? Зелёному новичку, который задаёт такие вопросы в Q&A?
Если что-то заработало в контейнере у одного человека, то у другого достаточно выполнить лишь одну команду для запуска. Всё подкачается и запустится само.
А вы о каких решениях говорили?

Зачем? Какой такой рендер? Вы реально усложняете простые вещи.

Тут спорить с вами не буду. Я говорил о рендере страниц в статику. Сталкивался с такой красивой и элегантной схемой, когда CMS использовалась специфически для публикации и администрирования, а всё в статику рендерилось специальная ферма, поднимаемая на несколько минут при обновлениях. В итоге сайт с овердофига страниц и отчетов держал огромные нагрузки, поскольку все страницы, включая комментарии пользователей, были доступны в виде статики. Так еще и клиентские машины не нагружались этим рендером. Короче согласен. Для обычных нужд, тем более нужд новичка такое излишне.

Для переноса / бекапа сайта надо:
- база (дамп)
- свой кастомный код (должно быть под гитом)
- сторонний код (сам WP, плагины и тд - в идеале должно устанавливаться/разворачиваться автоматом)
- медиа-файлы и прочий user generated content
- кастомный код, используемый только локально (конфиг или .env, плагины для dev-среды онли)

Всё правильно. Я не спорю.
А теперь представьте, что для развертывания всего этого нужно лишь положить архив бэкапа в папку и запустить одну команду с помощью докера.
Ну ок, еще env-файл с ключами и кредами

[Игорь Воротнёв]

Сергей Паньков,

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

Это не более чем personal preference. Большая часть разработчиков работает с достаточно узким стеком и никаких конфликтов не бывает от слова совсем. Я например работаю с PHP (WordPress, Laravel, Symfony), Javascript/Node.js, Go - это достаточно широкий стек, значительно шире типового - на macOS это все решается нативно через homebrew - valet в качестве сервера (nginx + php), MySQL/PostrgreSQL/SQLite/MongoDB, Redis, Memcached, ElasticSearch и еще парочка сервисов. В том числе 6 версий PHP, куча legacy проектов на поддержке. И никаких конфликтов. И работает на порядки быстрее. И работать в целом с этим значительно удобнее. Ну а если уж надо 1в1 воссоздать среду продакшна, тогда Vagrant и полноценная копия. Поймите меня правильно - я люблю докер и считаю его прекрасным инструментов. Для тех задач, для которых он создан. То, для чего вы его используете, к этим задачам не совсем относится. Делать так конечно можно, но форсить это как best practice для людей без опыта devops и контейнеризации я считаю совершенно лишним. Грубо говоря, докер имеет смысл только в конкретных use cases. И если у вас есть этот use case, то у вас к этому моменту уже есть devops отдел который знает что делать.

На счет "проще и понятнее" - это тоже лукавство. Проще и понятнее кому? Веб-мастеру с пятнадцатилетним стажем? Зелёному новичку, который задаёт такие вопросы в Q&A?

Да в целом всем проще. В первую очередь в командной среде и для онбординга новых людей. Да, сильная сторона докера в том, что он то как раз позволяет вроде как это дело упростить, унифицируя среду. По крайней мере таков promise. В реальности же баги самого докера на разных ОС и issues которые выплывают из этого зачастую не дебажатся вообще. И это в относительно больших командах случается значительно чаще, чем вы думаете. Я считаю что для каждой ОС и для каждого стека уже есть хорошие user friendly решения. Без докера.

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

Экспорт в статику можно сделать либо на этапе CI в deployment pipeline (вот для этого докер как раз и хорош), либо вообще на ходу через nginx fascgi_cache. Использовать для этого свою ферму имхо - усложнение. По сути - самопал вместо готовых специализированных инструментов (CI).

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

А представьте, что ни с какими архивами и докерами вообще возиться не надо. Клонируете проект в папку и делаете composer install, или ./make, или wp up. И все остальное делается само - с прода / стейджинга / посевов / shared snapshot создается актуальная база, синхронизируется UGC, ставится код и зависимости. Смысл в том, что сложности / зависимости и оптимальные процессы в разных проектах разные, и в разных командах разные. И только этот конкретный проект должен о них ведать. И в нем должен быть инструмент для разворачивания среды - будь то composer c его post-install скриптами, wp-cli c кастомными командами, gnu make, шелл скрипты - не важно. Это должно быть уникально для каждого проекта. На базе какого-то шаблона. И у каждой команды он может быть свой (например, у меня в одном из проектов все на маках, наемным разрабам маки предоставляют - значит среда именно этого проекта 100% будет оптимизирована под инструменты свойственные именно macOS). И все это в итоге ничем не хуже докера, но быстрее и эффективнее. И такое же гикое. И такое же оптимизированное и автоматизированное.

Но, опять же - мы с вами меряемся длиной достаточно сложных use cases, и что характерно - мы оба понимаем и используем докер (пусть и в разных случаях). Мой же коммент изначально к тому, что большинство типовых проектов (а это 90% разрабов и их заказов) вообще в этом всем не нуждается. Им достаточно по FTP слить с боевого, подключить git-репу c темой/плагином и все. И для этих задач им проще/удобнее какой-нибудь openserver или mamp.

[Сергей П]

Игорь Воротнёв, ок, вы меня убедили.