Кодить, админить, девопсить-вы серьезно?(

ну порой приходится да

наоборот здорово же

больше понимаешь работу других коллег

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

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

Еще можно добавить (как мне известно) НТ в основном в банковском секторе, следовательно там своя специфика. У меня например (в начале), много было трудностей именно с пониманием как решать рабочие проблемы в банке.

Дефекты также исправлять самостоятельно - задача НТ
Причины такие:
- в НТ часто самый большой стенд, с интеграцией
- в НТ много тестовых данных, больше тестовых случаев

=> только в НТ все это можно проверить, локализовать, а там и до исправления недалеко

часто что-то фиксится в ConfigMap (настройками), иногда кодом, но и тут можно помочь

Особенно классно, когда работа с бд сделана через вызовы хранимок а не через прямые запросы

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

+1

А ещё - если самому много чем заниматься, начинаешь куда лучше понимать, как оно всё работает

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

Фига себе

Я видел две схемы накатки релизов на бд:

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

При выполнении каждый запрос пишет флажок в бд, мол я отработал

И при накатке апдейтов это приложение - апдейтер имеет запросы от начала времён, и все отсутствующие выполняет

Очень удобно в плане того, что можно накатить на любой древности бэкап (только долго) и сразу видно, что в релизе поменялось


2) разрабы творят что хотят на своем дев-стенде, никто не знает, что поменялось в целом

При накатке релиза схему dev-стенда синхронизируют на другие стенды redgate-ом

Быстро, но разбираться, что там изменилось в релизе- адок


А вот такого, как ты сказал - не видел ни разу :)
Интересно, после каких событий они такую штуку ввели

http://rfinance.ru/magazine/?id=18170&aid=18199&tid=15
Вот эта система

Это как вариант 1. Миграции с контролем

Может даже liquibase так может делать. Не просто делать update, а смотреть на diff. У этого механизма миграций полно разных команд
https://docs.liquibase.com/commands/community/home.html

Возможно liquibase там и использовался. Не помню детали реализации. Технически можно
- при старте поднять пустую БД из миграций
- сгенерировать changelog между актуальной БД и поднятой
- применить changelog к актуальной БД, чтобы откатить все отличия

Вот как надо базы наполнять!
:)))

Коллеги как то наполнили БД тестовым данными пользователей. Там видимо использовался скрипт, который рандомно склеивал из заданных кусочков ФИО, получалось что-то вроде Толсточернопяткини Баллонг Сберович. Было очень тупо, но просто убило, а начальник не мог понять почему я все время ржу.

Спасибо за идею) надо попробовать

Это не моя идея :(