Pull to refresh

Comments 13

А существующие решения рассматривали? Если да, то какие и почему отклонили (было бы интересно почитать, возможно даже отдельным текстом)

У нас много систем для автоматизации релизов, типа Jenkins и Capistrano, но они занимаются релизами конкретных проектов. А тут же речь про все проекты компании. Такого зверя готового мы не нашли.
Надо было сразу упомянуть что это Slack-бот, а то по тегам и картинкам догадываться приходится
справедливо! сейчас исправлю
Я правильно понимаю, что у вас происходит по несколько релизов в день?
1 задача = 1 релиз?
Иногда несколько десятков релизов в день. Чаще всего — да. Одна задача — один релиз. Однако, бывают релизы из 2-3 задач.
А можете рассказать как проверяется задача перед релизом?
Для каждой задачи поднято свое окружение (например задача по беку) или они проверяются на каком-то общем «предрелизном»?
Просто меня немного смущают настолько частые релизы, так как код, по факту, проверяется на проде, так как нельзя предусмотреть всех изменений, которые внесли другими, уже одобренными, задачами. И вот хотелось бы узнать как часто у вас бывают, связанные с такой ситуацией, проблемы, и не думали ли вы пойти в сторону одного/двух релизов в день?
Перед релизом задача проходит ревью, потом тестирование в тестовой среде, потом нажимается волшебная кнопка в jenkins, которая делает rebase, потом прогоняет тесты, потом ставится тег. И уже потом релиз
Может ли возникнуть ситуация, когда на мою таску поставили тег готовности к релизу, а кто-то, пока моя задача стояла в очереди, зарелизил задачу, которая сломала мою ветку? И я об этом узнаю только после того, как мой код окажется на проде? И не получится ли так, что все тесты гонялись на неактуальной версии кода?
Ничего страшного, что в статье про бота мы обсуждаем процесс деплоя?)
у нас в backend(е) нет develop ветки. Разработчики выделяют свои ветки из мастера, так же у разработчиков нет прав на merge своей ветки в master, это делать только jenkins с обязательным прогоном тестов. То есть для каждой из веток тесты будут проведены правильно. Мы стараемся не мариновать уже смеренные задачи в master(e). И разработчик практически сразу после успешного прохождения тестов и успешного мержа отправляет запрос на выгрузку и ждет свободного админа, кто бы ему выгрузил код. И наш бот помогает нам как в раз в том что бы понять кто раньше захотел зарелизиться. Без него можно было прошептавших ошибиться и выгрузить последний тег, минуя тот которые еще не выгружен.

Вероятность того о чем вы говорите не нулевая, я говорю о том что может выгружено сразу 2 задачи вместо одной (при этом прогон тестов будет корректный), но есть очень много механизмов, которые не допускают этой ситуации.
Бизнес требует от нас больше чем 1-2 релиза в день. Так что нам приходится соответствовать. Код проверяется долго с помощью unit тестов, функциональных тестов и нагрузочных. Ну и к тому же мы предусматриваем процедуру отката и процедру плавных релизов на часть аудитории.
А как происходит распределение админских ресурсов ботом?
Сотрудникам с ролями админов в слак приходит уведомление, о новой задаче в очереди. Кто освобождается берет ее
Sign up to leave a comment.