Привет! У нас нет релизных веток, все релизы происходят через теги. Если что-то где-то поломалось, то мы просто делаем новый merger-request, в котором фиксим проблемы. Как такового fix flow у нас нет. Если надо что-то поправить, мы просто делаем новый исправляющий релиз.
У нас есть две тестовые среды: дев и превью. На дев мы раскатываемся во время разработки, превью при этом не задействуется. Деплой на все тестовые окружения происходит только после создания тега. После чего на превью среде, куда раскатился код под новым тегом, будет произведено тестирование нашего релиза. Ну и если все хорошо - едем на прод.
Привет! Выглядит очень прикольно на самом деле. Единственное чего пока не увидел из коробки - это redis sentinel, а у нас он везде используется. Возможно, это мои личные приколы, но я не очень понимаю, зачем изобретать велосипед и хранить инфру в коде, когда для этого уже есть хорошее и надежное решение в виде композа. Хотя, не отрицаю, что это может быть вполне удобно, надо потестить. В целом, выглядит как довольно хорошее решение для локальной разработки и CI.
Тогда нам очень повезло, что у нас такого нет.) В любом случае, в джобе статического анализа имеется переменная VERSION. С ее помощью ты можешь зафиксировать версию инструмента, если не хочешь, чтобы устанавливалась самая новая версия.
Привет! Мы посчитали, что лучше уж мы нагрузим раннеры и подождем полторы минутки на merge-request'е, чем будем гонять этот mypy только локально. Ведь если гонять его только локально - можно пропустить обновление и не исправить ошибки. Mypy - это тайпчекер и если он сыпет ошибками, то это хорошо, ведь это его основная задача А какое решение здесь видишь ты?
Привет! У нас нет релизных веток, все релизы происходят через теги.
Если что-то где-то поломалось, то мы просто делаем новый merger-request, в котором фиксим проблемы.
Как такового fix flow у нас нет. Если надо что-то поправить, мы просто делаем новый исправляющий релиз.
Да, у нас пока нет таких больших проектов. Все SAST проходят сразу на мастере, занимает около 3-ти секунд.
У нас есть две тестовые среды: дев и превью.
На дев мы раскатываемся во время разработки, превью при этом не задействуется.
Деплой на все тестовые окружения происходит только после создания тега. После чего на превью среде, куда раскатился код под новым тегом, будет произведено тестирование нашего релиза.
Ну и если все хорошо - едем на прод.
Привет! Выглядит очень прикольно на самом деле.
Единственное чего пока не увидел из коробки - это redis sentinel, а у нас он везде используется.
Возможно, это мои личные приколы, но я не очень понимаю, зачем изобретать велосипед и хранить инфру в коде, когда для этого уже есть хорошее и надежное решение в виде композа. Хотя, не отрицаю, что это может быть вполне удобно, надо потестить.
В целом, выглядит как довольно хорошее решение для локальной разработки и CI.
Тогда нам очень повезло, что у нас такого нет.)
В любом случае, в джобе статического анализа имеется переменная VERSION. С ее помощью ты можешь зафиксировать версию инструмента, если не хочешь, чтобы устанавливалась самая новая версия.
Привет! Мы посчитали, что лучше уж мы нагрузим раннеры и подождем полторы минутки на merge-request'е, чем будем гонять этот mypy только локально. Ведь если гонять его только локально - можно пропустить обновление и не исправить ошибки.
Mypy - это тайпчекер и если он сыпет ошибками, то это хорошо, ведь это его основная задача
А какое решение здесь видишь ты?