| Comments: |
А у вас сколько продов? Один или два?
А вы с какой целью интересуетесь?
Проектов два. Компонентов с версионированием задним числом 6. Серверов в сумме около 15.
Edited at 2019-06-12 11:51 (UTC)
Ну у нас два. Но и пиздюли за продолб, видимо, будут несопоставимы.
Собственно, у нас alpha, beta, prod backup, prod. И код движется слева направо. Фичи, как правило, можно включать и отключать налету на любом кластере. То есть имеется что-то вроде единого реестра настроек. Этот реестр покрывает только специфические и простые настройки. База, естественно, реплицирована на каждую машину.
Ну у нас в одном из проектов похожая схема:
- сервер бэкапов и инфраструктуры (на него реплицируется база с прода который прод)
- запасной прод, он же стейджинг. Независимая база, при переключении прода её затираем той, что со слейва репликации.
- конфиг фич тупо вкоммичен в сорцы, там свитч по хостнеймам. Ну то есть налету отключаемо, но это одна из форм хотфиксов. Надо помнить, что где отключено, что проще делать в сорс-контроле.
- девелоперские сервера (независимые минипродакшены 24/7)
У нас, к сожалению, система довольно большая, то есть, каждый кластер состоит из 4-5 серверов типа ваших 256Гб ОЗУ, которые вы на ebay'е покупаете. Соответственно, невозможно каждому разработчику выдать персональный dev, на котором он может делать всё, что хочет.
Была идея сделать "общий dev" - некоторый кластер, на который еженощно копируется α, ну, а днём каждый разработчик имеет практически права root. Вы про такую схему слышали - есть у неё какие-то фатальные косяки? И как, вообще, строятся dev кластеры в таком случае? Ну нельзя же каждому разработчику выдавать кластер.
> Надо помнить, что где отключено, что проще делать в сорс-контроле.
У нас для этого спец. механизм с историей, разной интроспекцией, правами доступа, разделением по группам и т.д. Действительно удобная и надёжная вещь. Но и контора громадная, надо сказать.
> У нас для этого спец. механизм с историей
Ну то есть конфиг это отдельный компонент по сути. Понятно.
> как, вообще, строятся dev кластеры в таком случае
У нас есть 4 механизма:
- можно использовать для тестирования часть компонентов со стейджинга, известных своей неубиваемостью. Им всё равно откуда таски приходят - со стейджинга или с дева. Можно даже одновременно.
- легковесный дев - то есть минимум узлов и минимум фич
- покомпонентные пускалки - есть возможность запустить компонент изолированно от кластера, в mock-окружении
- тесты (ну то есть уменьшение необходимости пускать интеграционные тесты)
Для выдачи разрабам кластеров можно пробовать виртуалки. Взять толстый сервер (сервера), на который помещается по памяти 4 максимально облегчённых кластера, и поставить туда 10 инстансов.
Может оказаться, что комбинация оверкоммита, запрета одновременно пускать более Х виртуалок (в очередь, сукины дети) и встроенной в VM дедупликации памяти (в ESXi из коробки) сработает в вашем случае.
Ещё может оказаться вариант арендовать мощностя на амазоне на время рабочего дня. Подымать в 7 утра по крону. Но опять же зависит от масштабов и бюджетов. Если на з-п уходит миллион в месяц, можно сравнить стоимости различных решений, может оказаться что не так и дорого.
Edited at 2019-06-13 15:10 (UTC)
Наверное staging - это наш prod2.
А так примерно как у вас. Немного, кстати, не раскрыта тема компонент. Ну когда часть компонент может быть заморожена.
У нас компоненты не заморожены, просто достигли стабильности здорового человека (не модифицируются годы, так как feature complete и все приоритетные баги пофикшены).
Соответственно деплой идёт всего одного-двух компонентов, и откатывать в случае чего надо только их.
semantic versioning как раз же для этого. Третья цифра для хотфиксов, вторая для фич. Тэги для помечания версий, release branches (оно таки книжное! https://producingoss.com/en/release-branches.html) для замораживания и работы над релизом, потом мерджатся обратно в транк. А проблему с тем, что реально понятно только постфактум из того, что я видел решают (частично) тем, что дробят процесс релиза на кучу этапов типа alpha -> beta -> release candidate 0 -> release candidate 1 и т.п., пока багов совсем мало явных багов не останется. В семантик вершининг 2.0 кстати этот хвост тоже описан (типа tensorflow 1.13.1-rc2)
TLDR: по большому счёту, моя мысль в том, что если релизов как таковых нету - получаются короткие цепочки "выкатывание-хотфиксы-откат", разделённые длинными интервалами. - выкатывание 1 - откат - выкатывание 2 - хотфикс - "cтабильная версия" - выкатывание 3 - "cтабильная версия" - выкатывание 4 --------- 1. Ну моя мысль как раз о том, что традиционная модель говно и не нужна, и превращается в фарс карго культа. Отличительная черта "книжности" в том, что "книжное" не работает. В нашей нетрадиционной™ хипсторской реальности с continuous delivery обычный release management (замораживания-мержи-бранчи-альфы-беты-QA-приёмка) заменяется на пункты 5-7 хуяк-хуяк. То есть абзацы 2-3 мимо кассы. 2. Semantic versioning не для этого. Ну то есть сразу по открытию ссылки https://semver.org/ читаем про API, packages и dependencies. Моё определение semver - это "semver - это схема версионирования интерфейсов с third parties для отслеживания обратной совместимости". То есть, если нет интерфейсов, third parties или совместимости - то semver мимо кассы. 3. Перепутаны фиксы и хотфиксы: https://en.wikipedia.org/wiki/HotfixThe term "hotfix" originally referred to software patches that were applied to "hot" systems; that is, systems which are live, currently running, and in production status rather than development status. For the developer, a hotfix implies that the change may have been made quickly and outside normal development and testing processes. 4. Проблему того, что понятно постфактум, решают многими способами. Например, достаточно широко распространены deprecated versions. Но это опять же, больше для пэкеджей. | |
