У нас есть собственный инструмент для семплирования и фикстуры для того, чтобы проводить тестирование нашего приложения. После семплирования данных мы готовим докер-образ, который пушим в наше облако. Из образа поднимаются базы, dev и test среда и другая инфраструктура (внешние индексы, различные кэши, очереди). На семпловых данных поднимается вся связанная инфраструктура. Таким образом, применение семпловых данных приводит к инициализации около десятка баз данных.
У всех наших разработчиков есть возможность развернуть локально dev окружение в контейнере, в котором они могуть вести разработку и деплоить код всеми доступными способами. Миграции проверяются командой DBA и мержатся для дальнейшего нагрузочного тестирования.
Инвалидировать и пересобирать заранее чужую ветку смысла нет, возможно эту ветку уже выкатили в прод. При нашем размере тестового пула пользователей такая ситуация возможна очень редко, так как ветка быстрее уходит в прод, чем «протухает».
У нас есть боевой пул пользователей и аналогично тестовый, только тестовый пул намного больше. Вы правы, так как схемы пересоздаются циклично и размер пула ограничен, то через какое-то время более новая сборка получает более ранний порядковый номер, тем самым обновляя информацию в журнале сборок. Ветка, которая «протухла» (отдала свою схему более новой сборке) лечится путем пересборки.
1. Атомарно нельзя выкатить несколько серверов с кодом приложения. Таким образом одновременно может вызываться старый и новый код на базе.
2. Быстрый деплой и особенно откат.
3. Проведение нагрузочного тестирования на staging (для сотен разработчиков * n веток потребуется очень много ресурсов для создания индивидуального staging окружения)
Для нас хранимые процедуры удобны, в первую очередь тем, что это безопасно, плюс не надо передавать гигабайты данных между базой и приложением. Удобно сделать несколько действий с разными таблицами в базе, а в приложение только отчитаться о том, что всё было выполнено успешно. Это действительно удобно.
dostapn, данная статья посвящена не сравнению существующих дэшбордов или хранилищ данных.
Если отойти от темы статьи и сравнить Grafana с Zabbix, то первое, что бросается в глаза — огромные проблемы Zabbix с UI/UX. Проект уходит своими корнями еще в конец 90-х, но на текущий момент лучше он не стал и удовольствия от работы с ним не испытываешь. Кстати, существует плагин grafana-zabbix. Плагин позволяет интегрировать Grafana в Zabbix и использует Zabbix в качестве источника данных, а Grafana в качестве дэшборда, который будет отображать данные в удобном для вас виде.
2. Быстрый деплой и особенно откат.
3. Проведение нагрузочного тестирования на staging (для сотен разработчиков * n веток потребуется очень много ресурсов для создания индивидуального staging окружения)
Если отойти от темы статьи и сравнить Grafana с Zabbix, то первое, что бросается в глаза — огромные проблемы Zabbix с UI/UX. Проект уходит своими корнями еще в конец 90-х, но на текущий момент лучше он не стал и удовольствия от работы с ним не испытываешь. Кстати, существует плагин grafana-zabbix. Плагин позволяет интегрировать Grafana в Zabbix и использует Zabbix в качестве источника данных, а Grafana в качестве дэшборда, который будет отображать данные в удобном для вас виде.