Всем привет! Такой вопрос мучает меня в последнее время: как вносить изменения в разрабатываемый сайт (или уже готовый), чтобы сохранялась следующая синхронизация:
— верстка у меня на webpack, на выходе получается бандл. Это хранится на github — файлы сайта и сдампленная база данных тоже хранится на гите, но уже под другим названием
Частые задачи: — внести мелкие изменения в скрипт — поправить одно слово. Сценарий: — git pull (вытягиваем с гита либо верстку, либо сам сайт) — npm install (если это верстка) или заливаем / обновляем базу данных (если сайт) — вносим изменения в стили (скрипты), собираем билд. (либо исправляем 1 слово, если это сайт) — скомпилированные стили копируем в сайт, чистим кэш, обновляем их версию с помощью параметра «?», чтобы у клиента браузер закачал свежие версии
Делаем дамп базы Заливаем все на хостинг Обновляем репозитории Выдыхаем
— Большой соблазн забить на синхронизацию всего и вся. Просто исправить слово или дописать кусочек кода.
Как вы решаете эту проблему? Неужели Docker?
WebAlt
Для поправить одно слово: Notepad + SFTP.
Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.
maushi
WebAlt #:
Для поправить одно слово: Notepad + SFTP.
Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.
Может быть я не до конца ясно выразился: в моем вопросе речь идет скорее об уменьшении временных затрат на синхронизацию репозиториев, локальной копии сайта и хостинга
Станислав
Ну только разве что на локалке делать все, потом сразу заливать, без версий и всего прочего. Вообще не пойму зачем такую муть наводить, купил внешний жесткий и складывай версии туда периодически вместе с базой данных.
Мне кажется гит в данном случае полезен когда команда разработчиков работает, а если один, смысла по сути то и нет.
Sly32
CI/CD вам в помощь. Настраиваете репозиторий а автодеплой из к примеру ветки мастер. И как только вы в нее пушите код- он автоматом деплоится на сервер. Хранить дамп бд в гите не самая правильная идея
Sly32
maushi : Как вы решаете эту проблему? Неужели Docker?
Как вам тут докер поможет?
Ms-Dred #: Мне кажется гит в данном случае полезен
Ключевой слово — кажется)
Aisamiery
У вас очень странный флоу.
Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?
Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.
Да сумбурно описал, но вы явно делаете что то не так ))
maushi
Sly32 #: CI/CD вам в помощь. Настраиваете репозиторий а автодеплой из к примеру ветки мастер. И как только вы в нее пушите код- он автоматом деплоится на сервер. Хранить дамп бд в гите не самая правильная идея
Подскажите, пожалуйста, как бы вы синхронизировали базы данных?
—-
Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.
Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).
И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.
И тогда флоу станет таким:
— изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает. или нет?
Aisamiery
maushi #:
Подскажите, пожалуйста, как бы вы синхронизировали базы данных?
Миграциями поддерживается синхронизация с бд, при том их можно как накатывать так и откатывать, если у вас куда то делаются бэкапы БД то актуальность локальной БД можно поддерживать при создании контейнера с БД в докер, а на прод вносить изменения через механизм миграций
maushi #:
Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.
Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).
И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.
И тогда флоу станет таким:
— изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает. или нет?
Докер распространяет образы, так тоже можно делать конечно, но есть одно большое но, пока вы делаете свое изменение в прод могут прилететь изменения в бд (формы, заказы и прочее) и тогда вы их потеряете
maushi
Aisamiery #:
У вас очень странный флоу.
Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?
Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.
Да сумбурно описал, но вы явно делаете что то не так ))
в 1 репозитории я храню верстку в 2 репозитории я храню файлы сайта и базу
Я просто работаю из дома и из работы, поэтому использую гит, а не внешний жесткий диск, как тут советовали выше.
в теории, можно и в одном репозитории все хранить, но сначала все-таки сайт верстается, а уже потом верстка натягивается на движок, ну все как обычно.
Про миграции я слышал, но как увязать это с моим текущим окружением плохо представляю. Если миграции это по сути дамп + php-код, который создает таблицы и наполняет их. То должен быть написан некий сервис развертывания базы при автодеплое.
То есть флоу должен быть таким:
— внесли изменения на локальном компьютере — сделали дамб базы (или миграцию) — задеплоили на гитхаб — в гитхабе сработал (видать) хук и произошел автодеплой на сервер — на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)
—— Есть какие-то библиотеки для удобной миграции базы?
Aisamiery
maushi #:
То есть флоу должен быть таким:
— внесли изменения на локальном компьютере — сделали дамб базы (или миграцию) — задеплоили на гитхаб — в гитхабе сработал (видать) хук и произошел автодеплой на сервер — на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)
—— Есть какие-то библиотеки для удобной миграции базы?
Миграция это код который вносит изменения в БД, а не дамп. Возможно есть и библиотеки, вы чем пользуетесь? в фреймворках это встроенная фича
maushi
Всем привет!
Такой вопрос мучает меня в последнее время: как вносить изменения в разрабатываемый сайт (или уже готовый), чтобы сохранялась следующая синхронизация:
— верстка у меня на webpack, на выходе получается бандл. Это хранится на github
— файлы сайта и сдампленная база данных тоже хранится на гите, но уже под другим названием
Частые задачи:
— внести мелкие изменения в скрипт
— поправить одно слово.
Сценарий:
— git pull (вытягиваем с гита либо верстку, либо сам сайт)
— npm install (если это верстка) или заливаем / обновляем базу данных (если сайт)
— вносим изменения в стили (скрипты), собираем билд. (либо исправляем 1 слово, если это сайт)
— скомпилированные стили копируем в сайт, чистим кэш, обновляем их версию с помощью параметра «?», чтобы у клиента браузер закачал свежие версии
Делаем дамп базы
Заливаем все на хостинг
Обновляем репозитории
Выдыхаем
— Большой соблазн забить на синхронизацию всего и вся.
Просто исправить слово или дописать кусочек кода.
Как вы решаете эту проблему? Неужели Docker?
WebAlt
Для поправить одно слово: Notepad + SFTP.
Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.
maushi
Для поправить одно слово: Notepad + SFTP.
Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.
Может быть я не до конца ясно выразился: в моем вопросе речь идет скорее об уменьшении временных затрат на синхронизацию репозиториев, локальной копии сайта и хостинга
Станислав
Ну только разве что на локалке делать все, потом сразу заливать, без версий и всего прочего. Вообще не пойму зачем такую муть наводить, купил внешний жесткий и складывай версии туда периодически вместе с базой данных.
Мне кажется гит в данном случае полезен когда команда разработчиков работает, а если один, смысла по сути то и нет.
Sly32
Sly32
Как вы решаете эту проблему? Неужели Docker?
Как вам тут докер поможет?
Мне кажется гит в данном случае полезен
Ключевой слово — кажется)
Aisamiery
У вас очень странный флоу.
Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?
Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.
Да сумбурно описал, но вы явно делаете что то не так ))
maushi
CI/CD вам в помощь. Настраиваете репозиторий а автодеплой из к примеру ветки мастер. И как только вы в нее пушите код- он автоматом деплоится на сервер. Хранить дамп бд в гите не самая правильная идея
Подскажите, пожалуйста, как бы вы синхронизировали базы данных?
—-
Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.
Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).
И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.
И тогда флоу станет таким:
— изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает.
или нет?
Aisamiery
Подскажите, пожалуйста, как бы вы синхронизировали базы данных?
Миграциями поддерживается синхронизация с бд, при том их можно как накатывать так и откатывать, если у вас куда то делаются бэкапы БД то актуальность локальной БД можно поддерживать при создании контейнера с БД в докер, а на прод вносить изменения через механизм миграций
Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.
Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).
И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.
И тогда флоу станет таким:
— изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает.
или нет?
Докер распространяет образы, так тоже можно делать конечно, но есть одно большое но, пока вы делаете свое изменение в прод могут прилететь изменения в бд (формы, заказы и прочее) и тогда вы их потеряете
maushi
У вас очень странный флоу.
Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?
Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.
Да сумбурно описал, но вы явно делаете что то не так ))
в 1 репозитории я храню верстку
в 2 репозитории я храню файлы сайта и базу
Я просто работаю из дома и из работы, поэтому использую гит, а не внешний жесткий диск, как тут советовали выше.
в теории, можно и в одном репозитории все хранить, но сначала все-таки сайт верстается, а уже потом верстка натягивается на движок, ну все как обычно.
Про миграции я слышал, но как увязать это с моим текущим окружением плохо представляю. Если миграции это по сути дамп + php-код, который создает таблицы и наполняет их. То должен быть написан некий сервис развертывания базы при автодеплое.
То есть флоу должен быть таким:
— внесли изменения на локальном компьютере
— сделали дамб базы (или миграцию)
— задеплоили на гитхаб
— в гитхабе сработал (видать) хук и произошел автодеплой на сервер
— на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)
——
Есть какие-то библиотеки для удобной миграции базы?
Aisamiery
То есть флоу должен быть таким:
— внесли изменения на локальном компьютере
— сделали дамб базы (или миграцию)
— задеплоили на гитхаб
— в гитхабе сработал (видать) хук и произошел автодеплой на сервер
— на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)
——
Есть какие-то библиотеки для удобной миграции базы?
Миграция это код который вносит изменения в БД, а не дамп. Возможно есть и библиотеки, вы чем пользуетесь? в фреймворках это встроенная фича