Control freak

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

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

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

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

Название релизов и пакетов

Методики определения названий релизов всем известны, волшебные четыре или три числа вы наверняка не раз видели, так что рассказывать об этом не буду. Упомяну только, что название релиза призвано отвечать на вопрос «когда».
Интереснее порассуждать, как лучше называть пакеты, отвечающие на вопрос «что»? Очевидно, что использовать последовательную нумерацию не имеет смысла – пятый по названию никогда не окажется пятым для выкладки. Правильнее ввести в название какое-то кодирование, например, таким образом:

TT-N.MM-name

где:

• TT – префикс типа тестирования пакета (возможные варианты: полное, автоматическое, упрощённое, без тестирования,…);
• N.MM – мажорная версия портала в целом (пакет содержит изменения одной компоненты, но если есть зависимость от других, полезно это указывать прямо в названии пакета);
• name – индивидуальное название пакета, описывающее обобщённый смысл входящих в пакет задач (например: selectwidgetfix, newforumtheme, etc).

Практика вместо теории:
Иногда, особенно если пакет состоит из мелких ничем не связанных задач, в качестве name можно использовать и числительные. Например, японские.

Объединение задач в пакет

Задач появляется много, и для каждой, после выполнения первичной оценки, необходимо найти место в подходящем пакете. Вот несколько основных принципов объединения задач:

• все задачи, относящиеся к большому проекту (или этапу проекта);
• несколько задач, меняющих одну и ту же функциональность (и делать несколько правок в едином месте удобнее, и на тестировании экономим);
• задачи с одинаковым типом тестирования (если четыре задачи из пяти можно тестировать по упрощённой схеме, пятую правильнее перенести в отдельный пакет);
• задачи, изменяющие один компонент (удобнее выкладывать компоненты независимо);
• задачи, которые можно успеть выполнить к дате очередного «окна» тестирования (из этого следует, что правильнее держать несколько пакетов с небольшим количеством задач в каждом, чем один очень большой);
• задачи близкого уровня сложности (не стоит задерживать выпуск мелкой фичи из-за длительного тестирования сложного функционала, лучше разнести их по пакетам – и по времени).

Включение задачи в пакет не ставит на ней несмываемое клеймо. Пока не начато тестирование, а иногда и после его начала, допустимо переносить задачи из одного пакета в другой, более подходящий.

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

Состав пакета и релиза

Пакет содержит:

• название и/или краткое описание назначения пакета;
• текущее состояние пакета, один из следующих вариантов:
  • активный – ведётся разработка;
  • ожидает тестирования – разработка завершена, ждём ресурс тестеров;
  • в тестировании – идёт тестирование и правка найденных багов;
  • ожидает выкладки – разработка и тестирование завершены, ждём «окно» для обновления боевых серверов;
  • архивный – вся деятельность по пакету завершена, заказанный функционал выложен на боевые сервера;
• список задач со ссылками на постановку;
• список веток системы контроля версий, используемых для обновления каждой компоненты;
• перечень изменяющихся компонент (для пакета в целом и для каждой задачи отдельно);
• тип тестирования;
• инструкции и test case’ы для тестирования (при необходимости);
• отчёт(ы) о тестировании;
• список найденных незакрытых багов, признанных некритичными для выкладки.

Практика вместо теории:
Обычно активный статус имеют около половины от общего количества актуальных пакетов. Остальные либо тестируются, либо чего-то ждут.

Релиз включает в себя:

• пакет (для выкладки которого на боевые сервера и был заведён данный релиз);
• дату выкладки;
• инструкцию по выкладке (если процесс деплоймента отличается от стандартного);
• план выкладки.

Использование пакетов другими командами

Внедрить пакеты в ежедневную работу своего отдела – недостаточно. Другим отделам ваши пакеты тоже должны быть полезны.

После включения задачи в пакет заказчик может отслеживать состояние как самого заказа, так и пакета в целом. Начата ли разработка или ещё можно внести какие-то изменения в постановку? Идёт ли тестирование или пора поинтересоваться, почему приоритет отдан другому пакету? Чтобы заказчику было удобно, нужно специальным образом организовать хранение описаний пакетов:

• постоянная доступность описания (никаких локальных документов и программ, все карточки пакетов и релизов должны быть выложены на общедоступные сетевые ресурсы: wiki, багтрекер, …);
• формат описания – очевидный, прозрачный, без излишних технологических подробностей;
• возможность получать нотификации об изменении статуса пакета;
• и, наконец, описание всегда должно быть актуальным.

Если с одной стороны вашего конвейера стоят заказчики, то с другой – тестеры. Чем раньше они узнают о пакетах, которые вскоре потребуют их внимания, чем качественнее описание предстоящего объёма и сложности проверок, тем оптимальнее будет в результате ваше с тестерами взаимодействие.

Разделение релизов и пакетов – недостатки предложенной схемы

Предложенная организация работы, построенная вокруг пакетов, предназначена и хорошо работает на большом потоке заказов, для обслуживания которого необходимо распараллеливание разработки и тестирования. Одна есть у описанной схемы и недостатки:

• Даже имеющий статус «ожидает выкладки» пакет не даёт представления о предстоящей дате выкладки. А заказчикам зачастую эта дата очень важна.
• Релиз заводится очень поздно, когда точно известно, какой из готовых на данный момент пакетов будет выложен в какой последовательности. На практике это означает, что сегодня я могу завести релиз на завтра, но даже на послезавтра – уже вряд ли. Насколько (не)удобна такая ситуация эксплуатации, согласятся ли они работать в режиме постоянного аврала – вопрос, требующий аккуратной проработки.

Подводя итог

Работа с пакетами – моя ежедневная реальность. Это работает, это очень удобно. Но – мне, нам, моей команде. Нужно ли вам разделение релизов и пакетов – кто знает? Попробуйте…

Пока я дала только самое общее описание пакетов как сущности. Далее я расскажу:

• о специфике и приёмах использования системы контроля версий при работе с пакетами;
• об использовании пакетов в процессе выкладки на боевые сервера.