DevOps нет, но вы держитесь: как разработчики запустили тесты на этапе MR

Тестирование функциональное. Межсервисное взаимодейсвтие на моках. По сборке результатов - стандартный coverage. Основное, что нас интересовало в рамках тестов - не поломать старые контракты и смотреть за покрытием тестами

DevOps нет, но вы держитесь: как разработчики запустили тесты на этапе MR

Этот паттерн был только на старте, когда было всего 3 сервиса. Все reqirements объединялись в один - requirements_all. Далее на базе него создавался "базовый образ". В образ python:3.10.12-slim - доставляли все библиотке из requirements_all. Далее на "базовом образе" уже все запускалось. По факту пересборка была редкой, так как зависимости редко добавлялись. Но на одном образе быстро прогонялись тесты. Ничего уже доустанавливать не нужно. Взяли образ - запустили тесты. Для проверки на МР самое то. Про вопрос - кто то забыл запустить - автоматический запуск тестов. И без прохождения тестов невозможно влить МР

DevOps нет, но вы держитесь: как разработчики запустили тесты на этапе MR

Прогон тестов на CI начали примерно через 2 месяца после старта проекта, но соглашесь, что чем раньше - тем лучше

DevOps нет, но вы держитесь: как разработчики запустили тесты на этапе MR

Полностью поддерживаю, но проект стартовал более 1.5 лет назад, и распространенность ИИ была на меньшем уровне

Как быстро собрать кубик для простых задач: играемся с TinyOLAP

Спасибо, полностью согласен насчет оркестра для полноценной системы

Как быстро собрать кубик для простых задач: играемся с TinyOLAP

Да, ClickHouse специализируется на аналитической обработке. Возможно, ее можно использовать в связке с OLAP.

Как быстро собрать кубик для простых задач: играемся с TinyOLAP

Спасибо, посмотрю, что за «зверь»

Как быстро собрать кубик для простых задач: играемся с TinyOLAP

Спасибо, видел это либу. Но, к сожалению, оч давно заброшена более 5 лет назад