Какой у вас жизненный цикл задач от постановки до релиза?
В процессе жизненного цикла задачи, от постановки до релиза, у нас возникают некоторые сложности. Вопрос как в менеджерам, там и к разработчикам)
Жизненный цикл:
- Надо сделать
- В работе
- Тестирование (после того, как разработчик выполнил задачу, переводит ее сюда, и ставит ответственным Тестировщика)
- В релиз (Тестировщики переводят сюда протестированные задачи, и ставят ответственного за релизы)
- Готово
Сложности именно в процессе перехода задачи из Тестирования в Релиз. Дело в том, что за релиз отвечают отдельные сотрудник, и как только у них появляется задача, они сразу пускают в релиз. А тестировщики не всегда понимают, что нельзя не каждую задачу можно сразу пускать В релиз (просто забирают ветку из GitHub), после Тестирования. Т.е. для некоторых задачи может быть необходимо запуск миграций и прочих системных задач, без который после Релиза продашн сломается.
Я предлагал, чтобы тестировщики, после тестирования переводили задачу обратно на разработчика, чтобы потом разработчик сам перенес ее в Релиз, и оставил необходимые комментарии (для запуска миграций и прочего) для специалистов, которые выпускают релиз. Но менеджеры говорят, что так нельзя из-за каких-то менеджерских процессов..
Интересно, как у других выстроен этот процесс и решаются подобные ситуации?
Ответы (1 шт):
Сами пункты у всех, скорее всего, будут более-менее одинаковыми - т.к. у вас перечислены статусы задачи. У нас, например, ревью есть между "в работе" и "тестированием" но это локальные проблемы.
У вас явно проблема в процессе, и если стадии заданы жестко, новые статусы вводить нельзя, назад по статусам перемещать нельзя, то решение у вас только одно - разработчики должны расписывать миграции и прочее, важное для релиза, до отдачи задачи тестировщикам.
Ну или убирать людей, которые занимаются ручным релизом и полностью автоматизировать процесс. Мы убрали, у нас релиз по мержу в мастер, и процесс выглядит так:
- Code
- Открытие пулла с метками "ждет подтверждения на тест", и "не тестировано". Если пулл требует миграций базы - то еще и "нужна миграция"
- Review (через PR в гитхабе). Ревьювер также вычитвает задачу на тестирование. Снимает метку "ждет подтверждения на тест" с пулла.
- Test. QA снимает метку "не тестирован" по результатам.
- Если есть метка "требует миграций" - генерируются миграции, если для них нужно тестирование - проводят отдельным пуллом.
- Любой пулл с "протестировано" и без "требует миграций" можно мержить.
- По мержу в мастер улетает в продакшн.