Вы никогда не сократите Тime Тo Мarket, если будете тестировать все фичи на одном сервере
Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.
Простите заранее за некоторый негатив
Сама задачи нескольких окружений под фичи - очень классная, в контексте тех самых очередей.
Но 90% того что приведено в обосновании - это диагноз системной проблемы в разработке и управлении беклогом в продукте, которая несколькими окружениями не лечится никак. Системные проблемы лечат системным образом, в том числе: несколько фич в параллель у разработчика, незаконченные фичи, конфликтующие фичи - что делать в интеграции и пр.
Может показаться, что несколько фичей в параллели у разработчика это плохо и лучше чтобы она была одна. Но по факту у разрабов даже с норм процессами получается так:
- сегодня закончил задачу, отдал смотреть тестировщику
- на след день взялся за небольшой баг, который надо побыстрее докатить до продакшна, быстро пофиксил и опять надо показать тестировщику
- дальше взялся за следующую крупную задачу, параллельно тестировщик выкатил фидбек по той первой задаче
В итоге процессы нормальные, а всё равно нужно 3 сервера — под первую задачу, где надо что-то пофиксить, под вторую, которую нужно срочно посмотреть и под третью, которую еще никто не видел
А насчет незаконченных и конфликтующих фичей — плохо если это происходит постоянно. Но если периодически в ответ на изменения ситуации в наши турбулентные времена надо что-то приостановить, то доделывать чисто из-за того что уже начали нелогично.
И если из-за этого приходится еще прикладывать усилия чтобы "оторвать" задачу с тестового сервера, то это вдвойне грустно
Так что система в процессах с частой сменой приоритетов поможет прям ОЧЕНЬ сильно, а в стандартных, нормальных поможет тоже сильно. Потому что как ни крути разработчик не будет ждать, пока тестер протестит задачу, он возьмет новую