Pull to refresh

Comments 13

Мы ставим инструменты статического анализа прямо во время выполнения джобы. Это позволяет нам использовать самые последние версии этих инструментов

Че-т какое-то стремное решение. Как частенько бывало с mypy, например - новый релиз, и "Oops!... I Did It Again" - 100500 ошибок. И нагружать этим раннеры - такое себе.

Привет! Мы посчитали, что лучше уж мы нагрузим раннеры и подождем полторы минутки на merge-request'е, чем будем гонять этот mypy только локально. Ведь если гонять его только локально - можно пропустить обновление и не исправить ошибки.
Mypy - это тайпчекер и если он сыпет ошибками, то это хорошо, ведь это его основная задача
А какое решение здесь видишь ты?

Начиная с команды, которая занимается (у нас, например) PCI DSS - нельзя без одобрения менять версии библиотек. Это - "рас". Любой merge request - это серьезная тема - это "двас", т.е. если произошли изменения в файле, которому 7-8 лет - то возможно легче отложить на полгода изменение версии линтера очередного. Устранение ошибок, выданных mypy, например, может затронуть сотни файлов, а это, опять же, может по-новой потянуть проверки безопасности, которые не все в автоматическом режиме.
Так работают в объединенном королевстве.

Тогда нам очень повезло, что у нас такого нет.)
В любом случае, в джобе статического анализа имеется переменная VERSION. С ее помощью ты можешь зафиксировать версию инструмента, если не хочешь, чтобы устанавливалась самая новая версия.

Обычно принято собирать отдельный образ в котором уже установлены все необходимые утилиты для тестов, анализа, проверок и т.д. с фиксированными версиями.

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

Что думаете о Testcontainers для поднятия инфраструктурных сервисов для тестов?

Привет! Выглядит очень прикольно на самом деле.
Единственное чего пока не увидел из коробки - это redis sentinel, а у нас он везде используется.
Возможно, это мои личные приколы, но я не очень понимаю, зачем изобретать велосипед и хранить инфру в коде, когда для этого уже есть хорошее и надежное решение в виде композа. Хотя, не отрицаю, что это может быть вполне удобно, надо потестить.
В целом, выглядит как довольно хорошее решение для локальной разработки и CI.

Почему деплоите сразу на все тестовые окружения? Обычно на них тестируются разные варианты.

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

Видимо, ваш проект все же небольшой. В нашем, например, один скан Fortify на безопасность шёл больше суток на отдельном мощном сервере с 256 GB памяти, иначе вылетал по нехватке памяти.

Да, у нас пока нет таких больших проектов. Все SAST проходят сразу на мастере, занимает около 3-ти секунд.

Спасибо за пост.

  • Оригинал предполагает создание релизов через ветки, у себя же мы решили делать релизы через теги.

Какой у вас workflow для fix релиза? Например, сделать из тега релизную ветку, сделать там fix, сделать тег, выкатить в прод.

Привет! У нас нет релизных веток, все релизы происходят через теги.
Если что-то где-то поломалось, то мы просто делаем новый merger-request, в котором фиксим проблемы.
Как такового fix flow у нас нет. Если надо что-то поправить, мы просто делаем новый исправляющий релиз.

Sign up to leave a comment.

Articles