Как собирать релиз frontend?

Question

[Артур]

Всем привет! Подскажите как правильно собирать релиз?
Есть команда разработки фронтенда.
Команда пилит фичи, каждый в своей ветке. После готовности по мнению разработчика, фича заливается на тестовую среду (она 1).
Команда запилила 50 фич, выложила их на тестирование.
В процессе тестирования баги правятся в тесте разными разработчиками (не всегда понятно чья задача породила баг)

Затем на ступает день Х.
В тестовой среде все 50 фич протестированы, баги пофикшены. И менеджер говорит - "на бой будем выкладывать только 40 из них, остальные в следующий релиз."

Как без боли выделить эти 40 фич из протестированной версии? Кто как организует процесс и как лучше?

Comments

[Mikhail Osher]

Менеджера уволить за такую фразу.

[uRoot]

Если у вас есть готовые и протестированные фичи, то зачем их откладывать на следующий релиз? Их тогда уже лучше и не делать вовсе.

Answer 1

[historydev]

Каждая фича по дефолту должна иметь свою ветку и во время работы сливать рабочее и нужное для релиза в главную.

Answer 2

[McBernar]

Ну так планируйте релиз.

Answer 3

[xmoonlight]

(Фронт-)Архитектура проекта должна поддерживать такого менеджера.
Иметь возможность "безболезненных" отключений фич.

Answer 4

[lukoie]

А как у вас спринты планировались, если может быть такой разброс между тем что сделали, и что будете выкатывать в релиз???

Comments

[Артур]

планировались как положено, но по окончанию спринта бизнес попросил часть функционала отложить