Git для новичков. Развёртывание проекта на VPS при помощи GitHub Actions через rsync

[dell2201]

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

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

Для просмотра ссылки Войди или Зарегистрируйся
Следующая статья , отображает название темы. После того как разработка закончилась, и ветки смержили и нужно выкатить в мастер ветку (или в какой решили сделать ветку на деплой) и выкатить на боевой.
Вся
Для просмотра ссылки Войди или Зарегистрируйся и
Для просмотра ссылки Войди или Зарегистрируйся
Вопрос. Кто знает, как выкатывать обновление базы данных, с локалки на боевой? ))) В Opencart миграций нет. В нем вообще ни чего нет)))

 

[razllivan]

Кто знает, как выкатывать обновление базы данных, с локалки на боевой? ))) В Opencart миграций нет. В нем вообще ни чего нет)))

С помощью Phinx, отдельная либа не зависящая от ОpenCart. Через нее можно миграции делать

 

[spbnew777]

Для обновления базы при деплое лучше завести версионируемые миграции: каждая схема меняется отдельным SQL или PHP-файлом с понятным номером, а CI запускает их после выкладки кода и перед переключением трафика. Перед миграцией стоит сделать резервную копию и не хранить доступы к базе в репозитории; для больших изменений полезно отдельно проверить откат.

 

[88788]

Перед миграцией стоит сделать резервную копию и не хранить доступы к базе в репозитории;

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

Такой подход занимает чуть больше времени при обновлении, но экономит на много больше времени, если что-то пошло не по плану(!) Start и stop, это быстро, это не rebuild =)

Доступы контролируются файлом .gitignore, все конфиг файлы всегда записываю обязательно в игнор, чтобы у меня подтягивались настройки, чтобы доступы не были в репозитарии, в репо создаю пустые файлы с доступами или настройками, при первом деплое подтягиваю эксемплы, заполняю в ручную при помощи nano или подтягиваю готовые с локального пк, в будущих обновлениях уже git не подтягивает эти файлы, так же если нужны правки в них, делаю в ручную.