1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
Вы по маркетинговым треш-страницам «вендоров» сравниваете? Или как оцениваете степень отставания и ее производную?
2) Простое маштабирование из коробки.
И что, горизонтальное масштабирование уже завезли и автоматический шардинг и по вертикали по горизонтали?
Для DW можно использовать и MySQL и PostgreSQL.
Озеро данных на SQL-базах, серьезно? :) Особенно на MySQL — без шуток, верный выбор!
отвратительный маркетинговый буллшит-материал, вероятно достойный продажников «вендора», но не достойный тех. специалистов и других приличных людей из штата крупного банка.
Нет, все дело в том, бывают не только внешние юзеры, но и внутренние и стараться понижать т2м для последних тоже необходимо, поскольку их customer satisfaction, хотя и не напрямую, но оказывает сильное влияние на бизнес-показали компании.
Действительно, наверное, стоило явно отметить, что под словом «бизнес» подразумевались любые подразделения, которые могут быть заказчиком продукта, в том числе и предназначенного для внутреннего пользователя, а не только явно приносящих прибыль непосредственно.
Совершенно верное замечание. В ответ на которое хотелось бы подчеркнуть, что процесс, при котором каждое изменение требует ручной выкатки на тестовую (ые) среду или хотя бы какого-бы то ни было участия гуманоидов, совершенно точно не сокращает пресловутый т2м, а скорее
всего даже вовсе действует обратным образом.
В конкретном случае, проект предназначен для внутренних пользователей, которых обслуживает очень похожий пайплайн, которые просто заточен на автоматический запуск контейнеров по определнной метке, которые, в свою очередь, возникают при появлении новых тегов в гит-е.
Моя и всех моих коллег светлая мечта постепенно прийти к решению, когда каждый сервис отдает некую health-check ручку, а система оркестрации за нее регулярно дергает.
Со всеми «новыми» системами так и делаем с самого начала, а вот с существующими приходится всякие подпорки придумывать, и в них и тоска и боль и страдание, как верно подметил коллега выше.
В данном проекте фронт-сервисов мало, поэтому просто руками дописываем, а близком по духу проекте по соседству используется схема, в которой используется docker-gen и прочие подобные штуки, когда вешается слушатель на события докера о появлении или смерти сервисов с определенными метками, генерирующий конфиг nginx-а.
да, элегантная и красивая схема, тоже думаем прийти к ней в скором времени, смотрим на разные варианты, думаем. Единственное, что всегда нужно думать о количестве разрабатываемых параллельно фич, а то сервера(ов) для запуска всех фича-бранчей может и не хватить, особенно если приложения достаточно монолитные и массивные :)
GitLab хорош и часто даже весьма прекрасен своей высокой степенью интеграции и функциональности во том числе и бесплатной редакции при условии, что все серые будни кода протекают внутри него (гит-репозиторий, код-ревью, ci/cd-сервер, etc). Если же какие-то части этой инфраструктуры живут отдельно, то в значительная часть функциональности в бесплатной редакции перестает быть доступной, а его платные редакции кажутся очень-очень платными.
Тем не менее, никто еще не ставил точки в вопросе выбора решения для подобных задач и GitLab в них не последний кандидат.
Мы сейчас пилотируем разные интегрированные решения, с более дружелюбным интерфейсом, чем старик Jenkins, в том числе и гитлаб, но пока, к сожалению, золотого грааля отыскать не удалось :-(
Огромный плюс Jenkins-а — наличие плагинов для любой кофеварки и достаточно посильный для многих Java-стэк разработчиков процесс написания собственных расширений.
Да, все в докере, а сами контейнеры уже по разному бывает, где-то на голом железе, где-то в виртуалках.
Мы уже какое-то количество лет весь новый софт и извне и разработанный внутри стараемся запускать в контейнерах, так всем проще. Исключения, конечно, случаются.
В случае контейнерезированных приложений такие штуки решаются совершенно просто — каждая выкатываемая версия — это тег докер-образа с номером версии + тег latest. Если надо откатиться, мы просто запускаем контейнер из образа с тегом -1 от текущей и все.
в конкретно описываемом случае наиболее важной задачей была возможность ведения активной разработки и демонстрации актуального состояния системы бизнес-заказчикам при условии, что наша система взаимодействует с реальными базами и различными штуками в банке, поэтому развернуто приложение было на одном хосте, но в нескольких экземплярах (гит-мастер, тест, прелайв и тп)
Думаю, при таком пофигизме самого Рокета, имеет смысл писать в Точку (tochka. com) — рокет входит в этот филиал, а у них с фидбеком все вроде бы весьма хорошо.
В дополнение, если указать больше 1 символа, «выскакивает» некий хелп с описанием ключей /install /y и прочих для установки-удаления-обновления юзерспейса. Только вот непонятно, какой ехе-ник вызывать с этими ключами, т.к. для bash.exe они не подходят…
Вы по маркетинговым треш-страницам «вендоров» сравниваете? Или как оцениваете степень отставания и ее производную?
И что, горизонтальное масштабирование уже завезли и автоматический шардинг и по вертикали по горизонтали?
Озеро данных на SQL-базах, серьезно? :) Особенно на MySQL — без шуток, верный выбор!
Действительно, наверное, стоило явно отметить, что под словом «бизнес» подразумевались любые подразделения, которые могут быть заказчиком продукта, в том числе и предназначенного для внутреннего пользователя, а не только явно приносящих прибыль непосредственно.
всего даже вовсе действует обратным образом.
В конкретном случае, проект предназначен для внутренних пользователей, которых обслуживает очень похожий пайплайн, которые просто заточен на автоматический запуск контейнеров по определнной метке, которые, в свою очередь, возникают при появлении новых тегов в гит-е.
Со всеми «новыми» системами так и делаем с самого начала, а вот с существующими приходится всякие подпорки придумывать, и в них и тоска и боль и страдание, как верно подметил коллега выше.
— в данном проекте используем обычный интерфейс
да, все верно
Тем не менее, никто еще не ставил точки в вопросе выбора решения для подобных задач и GitLab в них не последний кандидат.
Огромный плюс Jenkins-а — наличие плагинов для любой кофеварки и достаточно посильный для многих Java-стэк разработчиков процесс написания собственных расширений.
Мы уже какое-то количество лет весь новый софт и извне и разработанный внутри стараемся запускать в контейнерах, так всем проще. Исключения, конечно, случаются.
Амазон когда-то продавал книги, Нетфликс рассылал диски по почте, о Нокия вообще легенды ходят, что они торговали туалетной бумагой.
Все-таки между авиакомпанией и космосом чуть меньше расстояние, чем между X5 и локхид мартин.