Совместим наш цикл разработки ПО с открытостью бранчей.
1. Во время стадии кодирование, например, для версии 3.0
бранч с версией 3.0 является открытым.
2. Во время стадии тестирование и ремонт багов бранч явля-
ется условно закрытым — никакой код не может сохра-
няться в таком бранче, за исключением кода с починкой
для конкретного бага, при сохранении кода в CVS програм-
мист обязан указать номер открытого бага в СТБ, иначе CVS
не разрешит checkin. Именно такой статус у бранча после
заморозки кода и передачи кода тестировщикам.
3. После того как произошел релиз на машину для пользова-
телей и в этом релизе найден баг, у нас есть два варианта:
а) если баг некритический (например, отсутствует проверка
е-мейла пользователя на два "@"), то его можно отре
монтировать в следующем релизе, т.е. мы фиксируем код
только в стволе;
б) если баг критический (например, невозможно совершить
покупку), то нужно отремонтировать его и выпустить патч-
Цикл разработки ПО
119
релиз как можно быстрее. Для такого срочного ремонта
нужен формальный документ: процедура о неотложном
ремонте багов (Emergency Bug Fix Procedure)