Pull to refresh
82
5

Пользователь

Send message

Liquibase — это как Git для структуры БД. Гораздо меньше работы ляжет на плечи DevOps-разработчиков при обновлении и откате инстансов приложений.

Что существенно поменяется, если взять, например, 10м? :)

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

Конечно, есть — он и используется. Ведь механизм FFI (Foreign function interface) и создан для интеграции между языками https://ps-group.github.io/compilers/backend_ffi

Вероятнее всего, реализация возможности запуска 16-битных приложений в новейших версиях Windows слишком трудозатратна и бесперспективна с коммерческой точки зрения. Ресурсов требуется море, а профит оценят только небольшое число энтузиастов. Все-таки Microsoft — коммерческая организация, а Windows — это не open-source проект, поддерживаемый сообществом.

Да — но данная конструкция всего лишь отключает искажение имен (Name Mangling) для С++ кода (в С, напомню, ничего подобного нет). Но ничего не говорит о Calling Convention, то есть о технических особенностях вызова (cdecl это или скажем stdcall)

По умолчанию для компиляторов Microsoft и для ABI x64 — да. Но тут речь не про частности, а про общий случай - чтоб и MSVC "переварил" и MinGW и прочие Clang'и. А для этого нужно использовать __cdecl соглашение о вызовах

Тут речь не про приложения, а про целевую платформу. Цитата Microsoft (https://learn.microsoft.com/ru-ru/windows/win32/winprog64/running-32-bit-applications) отсюда: "Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений windows. Основная причина заключается в том, что дескриптор имеет 32 значимых бита в 64-разрядной версии Windows. Таким образом, дескрипторы не могут быть усечены и переданы в 16-разрядные приложения без потери данных. Попытки запуска 16-разрядных приложений завершаются сбоем со следующей ошибкой: ERROR_BAD_EXE_FORMAT."

Речь идет не о готовой плюсовой либе, а о расширении функциональности через готовое решение, написанное на С++. Берем этот код, если нужно — вносим необходимые изменения, собираем из него динамическую библиотеку и подключаем к нужному нам проекту. В статье мы пошагово расписали, как это сделать применительно к Java и Python. Про боль и страдания — вопрос субъективный 🙂

Под началом работы на проекте мы подразумеваем этап написания ТЗ, поэтому фактически контрольные точки мы определяем до старта разработки. И ревью архитектуры проводит архитектор не из команды проекта, чтобы избежать "замыленности взгляда".

Часть пунктов из вашего списка как раз у нас в выводах.

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

То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.

Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.

Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.

Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку.
Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании.
Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение.
Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.

Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.

Ваш посыл в целом здравый. Но все же отметать надежность на ранних этапах развития продукта может привести к тому, что он не “взлетит”.
Поэтому лучше искать золотую середину между скоростью и надежностью.

Спасибо за интерес и справедливое замечание. Расширили раздел про auto-accessor

Спасибо за замечание! Обновили статью, добавили описание методов контроллера, цепочку вызова и команду по запуску сервисов через javaagent. Надеемся, это поможет вам и другим читателям)

С проблемой нехватки слотов у архитекторов/senior мы тоже сталкивались. Но процедура проходит по новым процессам железно, не отменяем.

А замечание про выкатку на ограниченную аудиторию дельное. Спасибо!)

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

Действительно, было такое. Заменили

Спасибо за оценку и дополнение! Добавили его в материал

Спасибо за внимательность! Да, аутентификация. Поправили

Information

Rating
739-th
Location
Россия
Works in
Registered
Activity