Комментарии 13
Мы ставим инструменты статического анализа прямо во время выполнения джобы. Это позволяет нам использовать самые последние версии этих инструментов
Че-т какое-то стремное решение. Как частенько бывало с mypy, например - новый релиз, и "Oops!... I Did It Again" - 100500 ошибок. И нагружать этим раннеры - такое себе.
Привет! Мы посчитали, что лучше уж мы нагрузим раннеры и подождем полторы минутки на merge-request'е, чем будем гонять этот mypy только локально. Ведь если гонять его только локально - можно пропустить обновление и не исправить ошибки.
Mypy - это тайпчекер и если он сыпет ошибками, то это хорошо, ведь это его основная задача
А какое решение здесь видишь ты?
Начиная с команды, которая занимается (у нас, например) PCI DSS - нельзя без одобрения менять версии библиотек. Это - "рас". Любой merge request - это серьезная тема - это "двас", т.е. если произошли изменения в файле, которому 7-8 лет - то возможно легче отложить на полгода изменение версии линтера очередного. Устранение ошибок, выданных mypy, например, может затронуть сотни файлов, а это, опять же, может по-новой потянуть проверки безопасности, которые не все в автоматическом режиме.
Так работают в объединенном королевстве.
Обычно принято собирать отдельный образ в котором уже установлены все необходимые утилиты для тестов, анализа, проверок и т.д. с фиксированными версиями.
Этот запеченный образ и гоняют в пайплайне, подсовывая маунт с проектом
Что думаете о Testcontainers для поднятия инфраструктурных сервисов для тестов?
Привет! Выглядит очень прикольно на самом деле.
Единственное чего пока не увидел из коробки - это redis sentinel, а у нас он везде используется.
Возможно, это мои личные приколы, но я не очень понимаю, зачем изобретать велосипед и хранить инфру в коде, когда для этого уже есть хорошее и надежное решение в виде композа. Хотя, не отрицаю, что это может быть вполне удобно, надо потестить.
В целом, выглядит как довольно хорошее решение для локальной разработки и CI.
Почему деплоите сразу на все тестовые окружения? Обычно на них тестируются разные варианты.
У нас есть две тестовые среды: дев и превью.
На дев мы раскатываемся во время разработки, превью при этом не задействуется.
Деплой на все тестовые окружения происходит только после создания тега. После чего на превью среде, куда раскатился код под новым тегом, будет произведено тестирование нашего релиза.
Ну и если все хорошо - едем на прод.
Спасибо за пост.
Оригинал предполагает создание релизов через ветки, у себя же мы решили делать релизы через теги.
Какой у вас workflow для fix релиза? Например, сделать из тега релизную ветку, сделать там fix, сделать тег, выкатить в прод.
Удобный CI/CD доступен каждому