В общем, вы про изменение схем, зачастую необратимые.
В нашей схеме СУБД одна на оба спейса и блю и грин. Слишком много мороки с двумя активными инстансами постгрес, поэтому этим путем мы не пошли, принимая все недостатки такого подхода.
Ну и мы стараемся по максимуму исключить breaking changes со схемой данных БД. Не переименовывать колонки, а добавлять новые, не удалять старые и т.д. В 90% случаев, ломающих изменений можно избежать.
Если же все таки без них никак, то такие работы проводятся в неактивно для клиентов время. И держим под рукой скрипты отката, которые должны быть обязательно.
Крайне низкий, не больше 5 в квартал на наших масштабах. Но тут есть нюансы. Деплой по blue/green с canary раскаткой позволяет не оказывать никакого влияния на клиентов, даже если он неудачный. Такие кейсы не попадают в статистику Change Failure.
Но все же, бывают неудачные релизы и в этом случае, после переключения бОльшего процента трафика в грин. Вот такие да, увеличиваются счетчик фейлов, но повторюсь - таких кейсов крайне мало.
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
По change frequency я бы сказал был более долгий и плавный переход. Около полугода или больше. Тюнили пайплайны, какие то этапы отправляли в параллель.
В самой метрике учитываются любые поставки на prod. По сути фича и хотфикс ничем не отличаются - в обоих случаях делается поставка нового кода на прод, поэтому для нас это все попадает в метрику change frequency.
Какие временные интервалы между переходами?
Сильно зависит от фичи. Что то супер критичное, может и неделю раскатываться плавно.
Какие то менее критичные изменения, которые несут небольшие риски влияния на клиентов могут быть раскатаны за несколько часов.
К сожалению, у меня не было опыта работы с greenplum, но все же, выглядит так, что он больше подходит для построения DWH, больших Data Lake или же построения Big Data. У нас же была чуть иная задача - быстро и консистентно собирать данные с большого числа источников, упорядочивать их и точечно отдавать клиентам. При этом, по необходимости еще строить отчеты поверх этих данных. Citus позволил с минимальным оверхедом и небольшой надстройкой над PostgreSQL решить эту задачу. Greenplum тут виделся избыточным, и хотелось не оверинженирить.
В общем, вы про изменение схем, зачастую необратимые.
В нашей схеме СУБД одна на оба спейса и блю и грин. Слишком много мороки с двумя активными инстансами постгрес, поэтому этим путем мы не пошли, принимая все недостатки такого подхода.
Ну и мы стараемся по максимуму исключить breaking changes со схемой данных БД. Не переименовывать колонки, а добавлять новые, не удалять старые и т.д. В 90% случаев, ломающих изменений можно избежать.
Если же все таки без них никак, то такие работы проводятся в неактивно для клиентов время. И держим под рукой скрипты отката, которые должны быть обязательно.
Что подразумевается под релизами БД? Накат новой версии PostgreSQL?
Крайне низкий, не больше 5 в квартал на наших масштабах. Но тут есть нюансы. Деплой по blue/green с canary раскаткой позволяет не оказывать никакого влияния на клиентов, даже если он неудачный. Такие кейсы не попадают в статистику Change Failure.
Но все же, бывают неудачные релизы и в этом случае, после переключения бОльшего процента трафика в грин. Вот такие да, увеличиваются счетчик фейлов, но повторюсь - таких кейсов крайне мало.
По change frequency я бы сказал был более долгий и плавный переход. Около полугода или больше. Тюнили пайплайны, какие то этапы отправляли в параллель.
В самой метрике учитываются любые поставки на prod. По сути фича и хотфикс ничем не отличаются - в обоих случаях делается поставка нового кода на прод, поэтому для нас это все попадает в метрику change frequency.
Сильно зависит от фичи. Что то супер критичное, может и неделю раскатываться плавно.
Какие то менее критичные изменения, которые несут небольшие риски влияния на клиентов могут быть раскатаны за несколько часов.
Сори, коммент почему то отдельной веткой ушел, ответил ниже https://habr.com/ru/companies/gazprombank/articles/810477/comments/#comment_26905795
К сожалению, у меня не было опыта работы с greenplum, но все же, выглядит так, что он больше подходит для построения DWH, больших Data Lake или же построения Big Data. У нас же была чуть иная задача - быстро и консистентно собирать данные с большого числа источников, упорядочивать их и точечно отдавать клиентам. При этом, по необходимости еще строить отчеты поверх этих данных. Citus позволил с минимальным оверхедом и небольшой надстройкой над PostgreSQL решить эту задачу. Greenplum тут виделся избыточным, и хотелось не оверинженирить.
Постараюсь собраться с силами и запилить подобный пост со всеми техническими потрохами :) Про само устройство хранилища и его HA конфигурацию.