Size: a a a

2020 March 04

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
George Gaál
мне приходят пуши, что они списывают бабло
Кстати да, попробуй не гланге, а ЛК по прямой ссылке или App
источник

DK

Dmitry Kireev in DevOps
Vitalii Demianets
Всем привет!

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

Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.

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

У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?

Сразу спасибо добрым людям за помощь.
я бы сразу обговорил жесткие рамки. типа кастомизации нет. либо форкаете и в штат отдельных людей на поддержку этой кастомизации. баг. Определить рамки поддержки версий и старого клиента дропать просто.
источник

GG

George Gaál in DevOps
Vitalii Demianets
Всем привет!

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

Кратко обрисую ситуацию.
Мы реализовали онлайн приложение для своей компании. Сейчас это приложение мы продаем по формату лицензии на использование и WhiteLable. Уже есть прецедент 3-х продаж. Каждая лицензия имеет свой логотип, свой домен и свою БД. Инфраструктуру этих лицензий мы реализовали через ветки в Гит, тоесть 1 проект(1 лицензия) имеет свою ветку dev и master, которые отличаются от родительских только логотипами, доменами и БД.

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

У нас возник вопрос на почве этого:
1. Как обращаться с клиентами при такой ситуации (одному нужно обновление, а другому нет)?
2. Если в одного клиента ветка ушла очень далеко, ввиду новых обновлений, а у второго осталась на месте потому как он не хотел новые обновления и вдруг что то падает у двоих сразу, как им исправить этот баг? Двоим вручную?
3. Как бы Вы реализовали инфраструктуру, если бы знали что в любом случае будет такая ситуация, что каждому клиенту нужна своя кастомизация?

Сразу спасибо добрым людям за помощь.
Код у клиентов насколько кастомный будет ?
источник

GG

George Gaál in DevOps
Разворачиваете в контуре клиента ?
источник

GG

George Gaál in DevOps
Клиент доступ к инфре проекта имеет ? Или ему пофиг ?
источник

GG

George Gaál in DevOps
Выглядит, будто надо отделить конфигурационные параметры - домены, логотипы в отдельную сущность со своей админкой
источник

DK

Dmitry Kireev in DevOps
George Gaál
Выглядит, будто надо отделить конфигурационные параметры - домены, логотипы в отдельную сущность со своей админкой
Я думаю тут еще ожидания бизнеса нечеткие. "каждому клиенту нужна будет кастомизация" не совсем реально ожидать реализации такой ситуации.
источник

GG

George Gaál in DevOps
Ну, так надо по очь кол егам сформировать свои ожидания
источник

DK

Dmitry Kireev in DevOps
Dmitry Kireev
Я думаю тут еще ожидания бизнеса нечеткие. "каждому клиенту нужна будет кастомизация" не совсем реально ожидать реализации такой ситуации.
иначе получится адский комбайн типа Elastic Beanstalk с хуками и проблемами расширяемости (прости, @rare_case)
источник

як

я никуда не тороплюсь когда напьюсь тогда напьюсь in DevOps
Зачем ты богохульствуешь?
источник

AC

Alexander 😼 Chistyakov in DevOps
А? Что?
источник

AC

Alexander 😼 Chistyakov in DevOps
Elastic Beanstalk кусок говна
источник

DK

Dmitry Kireev in DevOps
George Gaál
Ну, так надо по очь кол егам сформировать свои ожидания
но мне реально интересно пощупать такую модель. когда есть общая кодовая база и типа-кастомные фичи
источник

AC

Alexander 😼 Chistyakov in DevOps
Но это объяснимо, он давно появился
источник

DK

Dmitry Kireev in DevOps
Alexander 😼 Chistyakov
Elastic Beanstalk кусок говна
он просто устарел. 4 года назад еще был неплох (за неимением живых альтернатив)
источник

AC

Alexander 😼 Chistyakov in DevOps
Ну да
источник

AC

Alexander 😼 Chistyakov in DevOps
Потому и кусок говна
источник

DK

Dmitry Kireev in DevOps
Эх, все так быстро поменялось
источник

GG

George Gaál in DevOps
Dmitry Kireev
но мне реально интересно пощупать такую модель. когда есть общая кодовая база и типа-кастомные фичи
Слушай
источник

GG

George Gaál in DevOps
Это очень дорого тащить уникальные фичи
источник