Control freak

В каком релизе и когда выйдет этот функционал? Сколько времени нужно на тестирование релиза и когда оно закончится? Сколько релизов выйдет за квартал? Такие привычные вопросы, такие естественные – и такие временами раздражающие.

Мне понадобилось несколько месяцев работы на конвейере, чтобы понять, что именно не устраивает в использовании релиза как консолидированной сущности для разработки, тестирования и выкладки функционала:

• Релиз появляется тогда, когда принято решение о необходимости выкладки того или иного набора задач на боевые сервера. Обновление боевой среды – процесс строго последовательный, и выложить седьмой релиз до пятого нельзя. Сохранение жёстко заданной последовательности не кажется проблемой при малом количестве релизов, медленной разработке и аккуратном планировании на несколько месяцев вперёд. Но как быть, если завтра к вам придут с задачей, которая должна появится на боевых уже послезавтра? Изменять заранее декларированную последовательность релизов? Нарушать нумерацию? Выпускать хотфиксы, являющиеся, по сути, мелкими релизами? Да, иногда можно и так – но нельзя ли лучше?
• Релиз многими воспринимается как нечто неделимое и неизменяемое. Не успели добавить заказ в девятый релиз? Увы, вам придётся подождать десятого. Нашли при тестировании баг? Выпускаем новый билд и тестируем его заново. О, как это негибко! И совершенно неприемлемо в условиях постоянной смены приоритетов и требований. Если я хочу уверенно жонглировать входящими задачами, выкидывая наверх то самую нужную сейчас, то наиболее готовую, то наименее опасную, я не могу позволить себе ни длительного планирования, ни отказов заказчику на том только основании, что текущий большой релиз уже давно в тестировании.

Решение нашлось простое: оставить за релизом только одну функцию – деплоймент, а разработку и тесно связанное с ней тестирование передать новой сущности – «пакету задач». При этом релизы остаются строго последовательными, а пакеты распараллеливаются на произвольное количество потоков.
Подробнее