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

[Andrey_Solomatin]

Все шло хорошо, команда росла, тесты писались, но запускались только на локальной машине перед коммитами. Наступил момент, когда нужно было внедрить автоматический прогон тестов на этапе Merge Request (MR).

Поздно начинаете, при современном увроне развития CI инструментов, прогон тестов на CI можно начинать с первого дня.

[Avangardio]

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

[pro100alf]

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

[Andrey_Solomatin]

Вы о чем? Это делается за полчаса по тьюториалам.

[pro100alf]

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

[Andrey_Solomatin]

А случаи когда один разработчик забыл запустить тесты и кто-то другой за него отдувался не случались?

[Andrey_Solomatin]

Теперь у нас есть несколько requirements.txt, можно объединить их вручную в один файл, но мы написали скрипт на python:

Поддерживать одинаковые версии библиотек для все сервисов это вызов. Зачем это нужно если каждый сервис в своём докере?

[pro100alf]

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

[Andrey_Solomatin]

Про вопрос - кто то забыл запустить - автоматический запуск тестов. И без прохождения тестов невозможно влить МР

Это был вопрос про период до внеlредния тестов на CI

[Andrey_Solomatin]

Но наш опыт показывает, что базовый образ — отличное решение для ускорения тестов в CI/CD.

Вы имеете ввиду один и тот-же для всех сервисов?

Под базовым обычно понимаюется образ на базе которого строятся все остальные образы (python:3.10.12-slim).

[Andrey_Solomatin]

Я с GitLab CI почти не работал. Но посмотрелы бы на екстенды вместо якорей.

extends is similar to anchors with additional flexibility and readability.

[jsirex]

как-то неаккуратненько:
yq: Error running jq: ScannerError: while scanning for the next token found character that cannot start any token  in "<stdin>", line 15, column 1.

[bossalex]

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

[pro100alf]

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