Как вы дорабатываете свои сайты?

12
M
На сайте с 24.01.2017
Offline
35
182

Всем привет!
Такой вопрос мучает меня в последнее время: как вносить изменения в разрабатываемый сайт (или уже готовый), чтобы сохранялась следующая синхронизация:

— верстка у меня на webpack, на выходе получается бандл. Это хранится на github
— файлы сайта и сдампленная база данных тоже хранится на гите, но уже под другим названием

Частые задачи:
— внести мелкие изменения в скрипт
— поправить одно слово.

Сценарий:
— git pull (вытягиваем с гита либо верстку, либо сам сайт)
— npm install (если это верстка) или заливаем / обновляем базу данных (если сайт)
— вносим изменения в стили (скрипты), собираем билд. (либо исправляем 1 слово, если это сайт)
— скомпилированные стили копируем в сайт, чистим кэш, обновляем их версию с помощью параметра "?", чтобы у клиента браузер закачал свежие версии

Делаем дамп базы
Заливаем все на хостинг
Обновляем репозитории
Выдыхаем


— Большой соблазн забить на синхронизацию всего и вся.
Просто исправить слово или дописать кусочек кода.

Как вы решаете эту проблему? Неужели Docker?


WebAlt
На сайте с 02.12.2007
Offline
223
#1

Для поправить одно слово: Notepad + SFTP.

Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.

Промокод на скидку 25%: [ 64821976 ] на сайтах: [ https://firstvds.ru ] - виртуальные серверы; [ https://1dedic.ru ] - выделенные серверы; [ https://ispserver.ru ] - хостинг, VPS/VDS, выделенные и облачные серверы с полным администрированием.
M
На сайте с 24.01.2017
Offline
35
#2
WebAlt #:

Для поправить одно слово: Notepad + SFTP.

Для изменений в файлах скрипта, JS, CSS и т.п.: Notepad + SFTP + тестовый поддомен для проверки работоспособности.

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

Станислав
На сайте с 27.12.2009
Offline
215
#3

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

Мне кажется гит в данном случае полезен когда команда разработчиков работает, а если один, смысла по сути  то и нет.

Мы там, где рады нас видеть.
S3
На сайте с 29.03.2012
Offline
238
#4
CI/CD вам в помощь. Настраиваете репозиторий а автодеплой из к примеру ветки мастер. И как только вы в нее пушите код- он автоматом деплоится на сервер. Хранить дамп бд в гите не самая правильная идея
S3
На сайте с 29.03.2012
Offline
238
#5
maushi :
Как вы решаете эту проблему? Неужели Docker?

Как вам тут докер поможет? 

Ms-Dred #:
Мне кажется гит в данном случае полезен

Ключевой слово - кажется)

Aisamiery
На сайте с 12.04.2015
Offline
219
#6

У вас очень странный флоу.

Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?

Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.

Да сумбурно описал, но вы явно делаете что то не так  ))

Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
M
На сайте с 24.01.2017
Offline
35
#7
Sly32 #:
CI/CD вам в помощь. Настраиваете репозиторий а автодеплой из к примеру ветки мастер. И как только вы в нее пушите код- он автоматом деплоится на сервер. Хранить дамп бд в гите не самая правильная идея

Подскажите, пожалуйста, как бы вы синхронизировали базы данных?

----

Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.

Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).

И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.

И тогда флоу станет таким: 

- изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает.
или нет?

Aisamiery
На сайте с 12.04.2015
Offline
219
#8
maushi #:

Подскажите, пожалуйста, как бы вы синхронизировали базы данных?

Миграциями поддерживается синхронизация с бд, при том их можно как накатывать так и откатывать, если у вас куда то делаются бэкапы БД то актуальность локальной БД можно поддерживать при создании контейнера с БД в докер, а на прод вносить изменения через механизм миграций

maushi #:

Докер мог бы помочь следующим образом (наверно): на локальном компьютере у нас полностью независимое окружение: все пути и пароли фактически в 1 контейнере.

Потом мы берем и разворачиваем копию этого контейнера (в терминах я не силен) на удаленном хостинге (VDS, видимо).

И при этом мы НЕ МЕНЯЕМ никакие пароли, никакие пути, вообще ничего.

И тогда флоу станет таким: 

- изменил на локальном компе контейнер, запаковал, залил на хостинг, там все развернулось и все работает.
или нет?

Докер распространяет образы, так тоже можно делать конечно, но есть одно большое но, пока вы делаете свое изменение в прод могут прилететь изменения в бд (формы, заказы и прочее) и тогда вы их потеряете

M
На сайте с 24.01.2017
Offline
35
#9
Aisamiery #:

У вас очень странный флоу.

Если нет разделения на команды, то зачем вам 2 репозитория? у вас второй сабмодулем подключен?

Обычно в гите хранится сайт (файлы) и можно положить стартовый дамп бд если очень хочется. Изменения в бд вносится через миграции, и настраивается автодеплой по гит хуку. Так что внести изменения через гит быстрее чем скопировать файл с сервера по сфтп, изменить и закачать новую версию.

Да сумбурно описал, но вы явно делаете что то не так  ))

в 1 репозитории я храню верстку
в 2 репозитории я храню файлы сайта и базу

Я просто работаю из дома и из работы, поэтому использую гит, а не внешний жесткий диск, как тут советовали выше.

в теории, можно и в одном репозитории все хранить, но сначала все-таки сайт верстается, а уже потом верстка натягивается на движок, ну все как обычно.

Про миграции я слышал, но как увязать это с моим текущим окружением плохо представляю. Если миграции это по сути дамп + php-код, который создает таблицы и наполняет их. То должен быть написан некий сервис развертывания базы при автодеплое.

То есть флоу должен быть таким:

- внесли изменения на локальном компьютере
- сделали дамб базы (или миграцию)
- задеплоили на гитхаб
- в гитхабе сработал (видать) хук и произошел автодеплой на сервер
- на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)

-----
Есть какие-то библиотеки для удобной миграции базы?

Aisamiery
На сайте с 12.04.2015
Offline
219
#10
maushi #:

То есть флоу должен быть таким:

- внесли изменения на локальном компьютере
- сделали дамб базы (или миграцию)
- задеплоили на гитхаб
- в гитхабе сработал (видать) хук и произошел автодеплой на сервер
- на сервере запустился процесс миграции (видать, старая база удалилась, залилась новая)

-----
Есть какие-то библиотеки для удобной миграции базы?

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

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий