як
2. бекапы не нужны. У тебя все должно быть развертываемо из репы
БД?
Size: a a a
2020 March 16
GG
Ваш gitdb предлагает рушить 1 и начинает залезать на поляну 3 (ведёт в конце концов к принципу, объявленному @yamlcoder'ом, т.е. git repo окончательно становится нечитабельной версионной базой данных)
насчет нечитабельности ты преувеличиваешь
GG
только если стейтфул, но это вообще отдельная и больная история в ЦЕЛОМ
ЕО
2. бекапы не нужны. У тебя все должно быть развертываемо из репы
Бекапы приложения же, а не инфры
LB
Еще раз есть кейс:
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
ИМХО норм подход, а как иначе?
GG
где хранится инфа, что в таком-то коммите инфра репы хранится такая-то версия артифакта?
в смысле ?
як
Еще раз есть кейс:
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
Хорошая инфраструктура, код для неё можно сделать общим, связать через сабмодули можно настройки зоны.
GG
Бекапы приложения же, а не инфры
ну, от приложения зависят )
GG
Еще раз есть кейс:
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
норм подход
GG
просто это та же история, что и с коробочным софтом )
GG
когда у тебя код и конфиги (окружение) отчуждены друг от друга
GG
и ниче. народ как-то живет
LB
@identw мне кстати https://github.com/ingydotnet/git-subrepo вместо сабмодулей очень зашло
BG
Еще раз есть кейс:
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
Одно и тоже приложение на куче платформ:
ios (весь мир но чаще Европа)
google (весь мир но чаще Европа)
tiktok (китай)
wechat (китай)
yahoojp (япония)
hangame (япония)
...
Самый простой способ - менеджить их отдельно. То что они деплоятся в разные кластера итак понятно (с этим проблем нет никаких). Ничего общего им не надо, базы данных тоже живут отдельно.
Помиго этого. Менедежер хочет деплоить каждую платформу отдельно. И контроллировать версию для каждой платформы.
Такой подход антипаттерн и легаси? Какой тогда подход в таком кейсе лучше и не будет антипаттерном?
прописать менеджеру с ноги боюсь. Ну или пусть заводит 5 проектов, потому что как только начнется расхождение версий хотя бы в две-три - жди развлекалова с бекпортами и прочего ( Нам приходилось черипикать в ветку, которую создавали из тега(
2020 March 17
PD
Привет, народ. Есть проблема:
предположим у меня в git-е есть основная ветка A в моём локальном репозитории, которая отстала от ветки A на удалёнке на несколько коммитов. От неё( от A ) на локалке ответвляется ветка B, на которой я в данный момент на локалке и нахожусь. Вопрос: как мне находясь на ветки B запуллить изменения из ветки A с сервера на ветку А на локальном репозитории, но таким образом, чтобы изменения из ветки A не перекидывались бы на локальную ветку B ?
предположим у меня в git-е есть основная ветка A в моём локальном репозитории, которая отстала от ветки A на удалёнке на несколько коммитов. От неё( от A ) на локалке ответвляется ветка B, на которой я в данный момент на локалке и нахожусь. Вопрос: как мне находясь на ветки B запуллить изменения из ветки A с сервера на ветку А на локальном репозитории, но таким образом, чтобы изменения из ветки A не перекидывались бы на локальную ветку B ?
PD
Я хз как будет выглядеть команда git pull тогда и какая стратегия слияния подойдёт, если дело и в ней тоже
GG
так сделай чекаут в ветку а и сделай пулл
GG
а потом вернись в ветку Б
PD
я не могу зачекаутиться так как на ветке B и ветке A разные релизы приложений и поэтому происходят конфликты при чекауте и вякания гита, что файлы мол перепишутся
А с форс чекаут на A такая же хрень. Правда не совсем:
"<file> not up to date. Cannot merge." Я пробовал начильный чекаут сделать, но ошибка таже и из за того, что у меня A как раз и отстала на несколько коммитов от A на удалённом репозитории
просто п******я в плохом смысле ситуация
А с форс чекаут на A такая же хрень. Правда не совсем:
"<file> not up to date. Cannot merge." Я пробовал начильный чекаут сделать, но ошибка таже и из за того, что у меня A как раз и отстала на несколько коммитов от A на удалённом репозитории
просто п******я в плохом смысле ситуация
PD
я не знаю: почему у нас не сделали релизы через метки, что уже плохо, но тем не менее у ветки A сверхстарые коммиты( год им исполнился даже больше )