Comments 39
В базе удобно потому, что, по моему опыту, бизнес регулярно выдает срочные правки: сию секунду убрать или вставиь то-то и то-то.
Мне кажется. с таким же успехом можно просто заходить на сервер и править код. Какая разница то, срочные правки же!
Бизнесу надо запретить почти всем пользователям выполнять операцию, которая раньше была вполне себе легитимной. Например сделать это новой настройкой уровня доступа. Естественно рассылаются новые должностные инструкции пользователям, согласовывается новое ТЗ/ЧТТ на изменение функционала поддерживаемой системы.
И конечно ждать его величество Бизнес очень не любит.
Что лучше?
Воткнуть триггер сегодня чтобы пользователи гарантированно перестали делать чего они не должны, и затем выкатить новый релиз по стандартной схеме?
или уповать на новые инструкции в ожидании релиза?
или запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой?
1) механизм релиза-хотфикса, который можно катить в любое время и который не блокируется текущими доработками
2) механизм для запуска миграций
Оба варианта выше в любом выкатываются из репозитория и предварительно проходят Code Review.
Еще хочу заметить, что бывает так, что даже во внутренней разработке может не быть доступа на запись в прод-базу у разработчиков, например, из-за требований внутреннего или внешнего аудита.
Да достаточно попасть под действие Sarbanes-Oxley Act (например, начать листиться на американской бирже и работать с деньгами), и у разрабов не будет никакого write-доступа ни к данным, ни к рабочему коду, все деплои только через код-ревью в 4 глаза.
Если честно, то я даже и не читал этот закон. К нам в один прекрасный день пришли аудиторы, посмотрели на разрабов, провели интервью с ними, посмотрели, как мы храним и пишем код, как релизим, и т.п… А через полгода из материнской компании спускают требования следовать рекомендациям, а там и отбор доступа у разрабов в прод, и вот это вот все. Но радует, что CI/CD-пайпалайн и зеленый мастер удалось отстоять.
В комментариях вполне разумные требования — чтобы на продакшене не болтался непойми кто, чтобы пароли менялись, чтобы бывшие сотрудники не сохраняли доступ и т.д.
Помимо прочего требуется иметь дизастер рикавери план — что делать в случае факапа. Судя по комментариям факап представляется такой мерзостью, о которой и думать противно; вот никто и не думает.
Вариант с отсутствием доступа вообще весь тред делает бессмысленным, поэтому предлагаю его не рассматривать.
Пусть без прямого доступа, но передать временную «миграцию» отдельно от общего решения всегда можно. Отличаться от прямого доступа это будет только в части того кто будет запускать скрипт.
На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.
А что мешает делать это через систему конфигурации или, о боже, добавить в приложение настройки прав для пользователей, которые можно хранить в бд? Более того, почти все системы так и делают.
А идея добавить на скорую руку какой-то триггер, который что-то будет делать (причем, разумеется, только на проде) настолько плохая, что мне кажется, комментировать ее бессмысленно.
Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать? Теперь ограничение потребовалось. Вся суть примера в изменившихся требованиях и вариантах их реализации.
А идея добавить на скорую руку какой-то триггер, который что-то будет делать (причем, разумеется, только на проде) настолько плохая, что мне кажется, комментировать ее бессмысленно.
Идея оставить заказчика наедине с его проблемами до ближайшего релиза не предоставляя обходных решений еще хуже.
Дело не в плохости «добавить на скорую руку какой-то триггер». Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win. Бизнес доволен оперативностью и спокойно ждет оплаченную доработку. Разработка довольна, что не надо делать все аврально.
Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win.
Так же можно и сразу менять код на проде, с бекпортом в репу. Проблема в том, что этот код не тестируется, не проходит CI и прочее-прочее-прочее. И, обычно, приводит к еще большим авралам.
Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать?
Я, конечно, дико извиняюсь, но есть вещи, которые подразумеваются в системе для бизнеса. Эта как раз одна из них.
Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Это не значит что надо переходить на Production Driven Development.
Это значит, что при рассмотрении конкретной ситуации, надо учитывать подобную возможность.
Если система доставки спроектирована как рассказывает VladimirVerstov
выше, то подобная возможность не будет использоваться.
Если система доставки нового кода от 4х недель и больше, то нельзя догматично отбрасывать возможность спасти больше данных заказчика прямым вмешательством (и конечно работать в сторону уменьшения времени доставки).
Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Количество таких ситуаций настолько мало, что рассматривать их всерьез не имеет смысла. То есть, если ваше приложение изначально разрабатывалось с прицелом на использование триггеров, то это еще пол беды (но это опять же сравнимо с Production Driver Development), а если нет, то вы вполне вероятно отхватите столько багов, что вполне возможно, дождетесь следующего релиза.
Ответ «через недельку, бог даст, выкатим» не считается — ну или пусть программист оплачивает потери бизнеса самостоятельно.
Имхо, все эти рекомендации актуальны практически для любой реляционной субд. Не считая мелких различий, общие принципы остаются везде одни и те же. Начиная с антикварных Адабас и SystemR образца 1971 года.
И вообще, спасибо товарищам Бойсу и Кодду, за создание стройной и красивой теории баз данных.
Уже 10 лет как не смешно про удобство кода в базе, я уже не говорю про "долгую" компиляцию и выкладку, когда все на микросервисах с автодеплоем. Это базизм головного мозга — когда ты базист, код в базе кажется самым удобным)))
Ни качество разработки, ни скалируемость, ни выразительность, ни удобство, ни стабильность — а именно скорость.
Ага.
Тот случай, когда читаешь и думаешь: "Это должен был написать я!" :)
Типичные ошибки при работе с PostgreSQL. Часть 1