*** ВНИМАНИЕ: Блог переехал на другой адрес - demin.ws ***

воскресенье, 17 мая 2009 г.

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

Как мне кажется, в нынешнем мире программного обеспечения появилась доминирующая политика выпуска релизов/версий продукта. Эта политика основана не на факте появления новых возможностей или исправления ошибок, а просто на временных интервалах. А новые возможности и исправления ошибок просто вписываются в график релизов. То есть фраза «когда выйдет новая версия, то мы…» трансформируется в «когда такого-то числа выйдет следующая версия, то мы…».

Данный подход удобен всем. Разработчики в этом случае могу спокойно планировать свои спринты, распределяя по ним план развития продукта, а клиенты могут посмотреть на план этот развития (например, мы его публикуем на сайте поддержки) и понять, что и когда им ждать. Их планирование также упрощается.

Есть тут небольшая загвоздка – это исправление ошибок. Оценить время исправления коварного бага порой не так просто. Хорошо, что такие случаи, скорее всего исключения, так как если они становятся правилом, то возникает вопрос просто о качестве софта в целом.

Мы выпускаем релизы каждый месяц. Мне, как так называемому branch owner’у (я не очень люблю использовать английские слова, но вот «ответственный за версию» как-то уж очень коряво звучит), гораздо проще составлять списки патчей для включения в релиз и планировать окна тестирования, когда дата выпуска всегда постоянна. Конечно, интервал релизов подобран так, чтобы не приходилось выпускать пустые релизы без каких-либо патчей.

И каковы ваши наблюдения на этот счет?

6 комментариев:

  1. "в нынешнем мире программного обеспечения появилась доминирующая политика выпуска релизов ... на временных интервалах"
    Не у всех, не у всех, далеко не у всех.

    "Мы выпускаем релизы каждый месяц."
    Вау, я серьезно.

    ОтветитьУдалить
  2. У долгоиграющих проектов с вытекающим из этого факта активным супортом - это очень разумная и удобная политика.

    А по поводу релизов -- да. Месяц - это отличное время, что бы разобраться с пятком багов, обновить документацию, перетащить пару фич из разработки и т.д. Для нас этот период пока оптимален.

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

    ОтветитьУдалить
  4. У нас есть разделение - maintenance релизы и релизы нового продукта. Если первые делаются не по времени, а по готовности (исправлено X критических багов, стоит выпустить версию 1.01 и т.п.), то вторые - по времени. Но не раз в месяц, а раз в год. Год - достаточное время на то, чтобы наделать новых фич :)

    ОтветитьУдалить
  5. У нас период выпуска релиза - около половины года.

    >Мы выпускаем релизы каждый месяц.
    А не слишком ли быстро растет нумерация релизов? Мне кажется, что это сложно для программиста вспомнить что вошло в релиз, который был месяцев 7 назад.

    ОтветитьУдалить
  6. bishop: У нас похожая схема. Под релизами я имел ввиду именно maintenance, то есть багфиксы в основном, хотя иногда и новый функционал добавляется, если он не ломает обратную совместимость. Обратная же совместимость может быть нарушена только в новой версии/поколении, которая официально анонсируется раз в год.

    sanchosz: Программисту не надо это вспоминать. Каждые релиз сопровождается автоматической генерацией change-листа и списком версионных зависимостей между компонентами, чтобы можно быть автоматически воссоздать полную среду, работая в которой, клиент обраружил проблему.

    ОтветитьУдалить