TgQuestions
а почему просто миграцию при деплое не делать? сделать модуль для миграции
так вон же в "скрипте" sql_migrate вызов - миграции как раз?
норм деплой пайплайн?))))
для конкретики $branch = featureA; rm -rf project git clone myRepo project; mysql ... "drop database project" $latest_sql_backup = /backups/latest.sql mysql ... "create database project && source $latest_sql_backup" cd project git co $branch; sql_migrate done
ну да, но вопрос-то в самом подходе был, насколько вообще так нормально делать (исопльзоват ьскрипт, реплицирующий прод и накатывающий апдейт). Потому что я не нагуглил чот ничего полезного на эту тему. Местами только общие слова типа "staging is as close as possible to production environment"
Я не понял про гитлаб и даёт сервера
ну ты говоришь "используй гитлаб си".
Я не вижу принципиально никакой разницы между "используй гитлаб си" и "запускай локально скрипт деплоя". Ну да, гитлаб может автоматически скрипт сам запускать, но это вот вообще неважно же) Пока скрипта нет)
Я не вижу принципиально никакой разницы между "используй гитлаб си" и "запускай локально скрипт деплоя". Ну да, гитлаб может автоматически скрипт сам запускать, но это вот вообще неважно же) Пока скрипта нет)
так гитлаб CI же это просто выполнялка скриптов, как я понял, ну т.е. она серверов не предоставляет своих (бесплатно, по крайней мере). И все опять сводится к тому, нормально ли писат ьскрипт, берущий бекап прода и накатывающий обновления бд?
и да, к слову, бэкграунд, почему именно так хочется - потому что сейчас есть просто некий "тестовый сервер", на котором залита хрен знает какая база и хрен знает какие сорцы. Сорцы я обновлял, но пару раз обнаруживалось, что базы уже разъехались с продакшеном и ничего не работает
не работает из-за расхождения в схеме или из-за данных?
в схеме
Все можно сделать на bash скриптах при желании, но вот управляемость и поддерживаемость этого решения очень спорна. Гитхаб CI позволяет генерировать пайплайн из кода, со всеми прилегающими плюшками.
Это примерно как админить серв руками, или манажить один серв ансиблом с ролями и прочим
Это примерно как админить серв руками, или манажить один серв ансиблом с ролями и прочим
а у меня мой скрипт деплоя в коде) И мой скрипт же абсолютно ничем принципиально не отличается от yaml-скрипта для гитлаба или трэвиса)
С докером все в миллион раз легче
Gitlab ci
да, это есть, слово слышал
Да, у нас тут сто есть на примете, хорошо впишется в ваш стек
хочу реплику прода + мои новые фичи, вот :)
а по каким ключевым словам гуглить про вот это "деплой стейджинг база данных гит ветки"? Просто про деплой 100500 статей, про стейджинг тоже, а вот про то, как ДБ поднимать не особо написано... кажется, что все какие-то искусственные базы с 10 элементами используют и все
Си ди эн
а что вы смеетесь, если в вордпрессе ставить плагин один, то он бесплатный cdn для всех картинок предлагает :)
я не в курсе, вполне возможно, что это не сервер даже, а десктопный пека :)
На проде?
ну работает же)
Там прод в 10 юников
Бп без горячей замены?
200 Гб говоришь
да. Ну ок, с парой остановок, меняли БП и жесткий диск
А данные вы где храните
зато он работает 15 лет без остановки :)
Сервак????
Главное докер не забудь
Вы на чем хостите
есть VPS для вот всяких стейджингов, а прод на физическом серваке отдельном