а я чёт вспоминал как-то. У меня использование CONSTRAINT не было толком. Только в эксклюзивных случаях

А часто вообще у вас в логи системы падает ошибка о том, что какой то негодяй violation для констрейнта хотел устроить?

Хотите - расскажу один кейс, который сильно перевернул меня в сторону как раз такого "недоверия"?

Реальный кейс из реального проекта

Именно!

Реальный кейс всегда интересно

ладно, давно хотел спросить более насущное. вот все тут документацию по архитектуре, коду, базам ведут (точнее борются чтобы она велась, и хотя бы не очень устаревшая).
а документация по процессам?
оно надо, или с ней тебя легко заменить ?)
насколько оно вобще распространено (не разу не сталкивался)

Много занесли?

неа, вообще не занесли. Когда заносят - красивый пост получается с эмоджи и всякими там высокопарными словами

Косплеил утечкой акков?)

Это отдельная строчка в прайсе: "как будто не занесли"

не, доступностью пока только

утечкой акков спецбатальон техподдержки занимается удалённо

Рекомендую документировать build process. Ещё было б здорово release process. Если применяете Scrum, обязательно Definition of Done.

На мой взгляд, самый полезный тип документации процесса - new starter onboarding - что нужно сделать, чтоб новый человек стал продуктивным членом команды. Иначе даже через неделю у человека может не быть прав на изменение кода, например. Или, о чудо, компиляцию на локальном компьютере

Итак, кейс.

Мы делали систему, которая с одной стороны взаимодействует с SAP клиента, с другой стороны - с ФГИС МДЛП (система отслеживания движения лекарственных препаратов).

Одна из задач была проста:
- SAP выгружает в сетевую папочку накладную
- мы туда смотрим периодически
- видим новую накладную
- читаем
- вытаскиваем из нее номера упаковок
- идем в МДЛП и узнаем - были ли реально эти упаковки отгружены ранее по этой накладной
- если да - то разрешаем принять на склад партию

Задачу решили быстро, на тестовом стенде всё летает. Стали сдавать.
Но перед сдачей решили посоветоваться со знающим челом.

Он и говорит - код не пройдет аудит.

Я аж сел. Что там может не пройти-то? Всё красиво, по стандартам, тестами покрыто, граничные случаи учтены, что не так-то?

Ответ:
У вас не хранятся доказательства получения накладной.
Мало смотреть в сетевую папку. Нужно, как только видите новый файл, утащить его к себе, сохранить в надежное хранилище, сохранить в базу дату-время, имя файла, контрольную сумму.

Иначе вы никогда не докажете, что а) накладная была и что б) она была именно такой
Вас мгновенно подставят, изменив ее задним числом и обвинят в том, что код забагованный и из-за него теперь все беды.

А вы тут про DROP CONSTRAINT рассуждаете всерьез...

Компиляция на локальном компьютере норм. Более того, возможность запуска чего угодно с локального компьютера (при наличии необходимых доступов) - это пример нормальной автоматизации. Пример хуевой автоматизации, это когда запуск можно сделать только через CI/CD систему. Стоит ей чуток прилечь не дай бог и все пизда всему.

Ну и в любом руководстве по DevOps написано: CI/CD это просто система для запуска автоматизации которую вы написали где то в другом месте и которую при надобности можно запустить из любого компьютера с которого вам нужно.

а теперь докажите что накладную вы вытащили, а не нарисовали у себя в фотошопе, и засунули себе в базу задним числом

👍 жизненно. Я примерно такого же подхода придерживаюсь при общении по Websphere MQ. Получил сообщение и сохранил копию на случай разбирательств. Но если есть Apache Kafka, то это уже излишне

Ну выгружать в папочку такое себе