AS
а разраба зачем в прод выпустил с таким ? не sre чтоли ? с командой не поработал да?
Size: a a a
2020 March 03
як
Можно универсально тебе отвечать: "Не знаю, но че-нить нагуглим" :)
мне лень каждый раз повторять это. мошт табличку сделать?
DN
мне лень каждый раз повторять это. мошт табличку сделать?
что именно? "я пойду нагуглю"?
як
что именно? "я пойду нагуглю"?
да, примерно так и говорю. «я предпочитаю тестовые, прособеседовав меня не ждите "вах, усэ были паражены!"»
VD
Всем привет!
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
АП
Всем привет!
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
А лицензия точно должна иметь логотип?
Репа приложения должна быть одна, логотип и подключение к бд вынести на уровень конфига
Репа приложения должна быть одна, логотип и подключение к бд вынести на уровень конфига
як
Всем привет!
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
у меня есть ответ. нужно полгода и миллион рублей
AS
Всем привет!
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
Обращаюсь к Вам за помощью в решении на мой взгляд не простого архитектурного/серверного/девопсного вопроса по поводу работы онлайн приложения.
Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.
Сейчас проблем нет и все же, в дальнейшем прогнозируем, что каждый клиент захочет кастомизировать свою лицензию или же, например один клиент захочет новое обновление ставить, а другой скажет это мне это НЕ нужно в любом случае.
У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?
Сразу спасибо добрым людям за помощь.
Ведите проекты независимо, но как форки от одной кодовой базы. Если что-то общее напишете или закроете баг - забираете в каждый проект. А что-то персональное - оставляйте в форке.
AS
и общую ветку на две версии поддерживаемых делите, стейбл и current
AS
кто не захочет новые версии получать - будет на более старой версии сидеть но получать фиксы багов
АП
Можно ещё подключение к бд защить в метадату лицензии, чтобы они днс-имя базы не могли сменить 🌚
як
А лицензия точно должна иметь логотип?
Репа приложения должна быть одна, логотип и подключение к бд вынести на уровень конфига
Репа приложения должна быть одна, логотип и подключение к бд вынести на уровень конфига
не конфига, а окружения, тогда юзерам будет удобнее - им можно будет дать попользоватьСЯ ТЕСТОВОЙ/БЕТА версией - с новым билдом кода и новой схемой базы, но на изолированной (новой/зеркальной) копии их реальных данных
АП
не конфига, а окружения, тогда юзерам будет удобнее - им можно будет дать попользоватьСЯ ТЕСТОВОЙ/БЕТА версией - с новым билдом кода и новой схемой базы, но на изолированной (новой/зеркальной) копии их реальных данных
+
як
а разраба зачем в прод выпустил с таким ? не sre чтоли ? с командой не поработал да?
почему в прод? я не пускал 😊
AS
ох уж мне эти синтетические проблемы
як
Ведите проекты независимо, но как форки от одной кодовой базы. Если что-то общее напишете или закроете баг - забираете в каждый проект. А что-то персональное - оставляйте в форке.
бэкпортирование на старые версии. IMHO можно попытаться заказанные одним юзером фичи продавать другим - плагины, темы, кастомные отчёты и т.д.
AS
в ноке мы делаем механизм custom куда укладываются правки для клиента. брендинги и прочее. они живут в отдельной репе и в коде везде сделаны лоадеры.
лоадер сначала ищет в кастоме потом в основном коде.
разьезжание версий между клиентами пофиксить можно через фичатоглеры но это довольно дорого
лоадер сначала ищет в кастоме потом в основном коде.
разьезжание версий между клиентами пофиксить можно через фичатоглеры но это довольно дорого
AS
тоесть каждому клиента тащить всегда условно latest версию и включать фичи либо через файл лицензии либо через конфиг. в зависимомсти от жадности и глупости
АП
тоесть каждому клиента тащить всегда условно latest версию и включать фичи либо через файл лицензии либо через конфиг. в зависимомсти от жадности и глупости
