среда, марта 10, 2010

Versions

Я уже как-то писал про нумерацию версий на RSDN. Возникла нужда сослаться, так что выношу тот пост сюда с некоторыми изменениями.

Для чего вообще нужна нумерация версий? Самый простой и очевидный ответ: для идентификации сборок выходящих из рук разработчиков. Номер версии должен помогать отвечать на вопросы: Это одинаковые версии или разные? Какая из них была выпущена раньше? Что поменялось со времени предыдущей версии? Что нужно сделать, чтобы собрать точно такую же версию?

Не стоит путать внутренний и маркетинговый номера версий. Если меркетинг хочет чтобы какая-то версия называлась Gold Enterprise Platinum Edition 7.0 то это никак не влияет на внутренний номер версии.

Простая и в то же время достаточная система именования версий используют комбинацию из четырех чисел, записанных через точку: major.minor.hotfix.build

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

major — основной номер версии. Переход от одной основной версии к другой означает существенные изменения, часто вызывающие несовместимость с предыдущей версией без дополнительных ухищрений. Смена формата данных, глобальный рефакторинг, редизайн, существенное изменение функционала — достаточные основания для увеличения версии. Исправления багов, даже самых злокозненных, нет. Это число может только инкрементироваться. Увеличение major версии на единицу сбрасывает minor и hotfix в ноль. Традиционно, до релиза major версии равен нулю, с тем, чтобы в момент релиза выкатить пользователям 1.0.0.xxxx и в дальнейшем считать от него.

minor — дополнительный номер версии. Это номер небольшого изменения в рамках версии. Это может быть появление нового функционала, совместимое изменение формата данных и т.п.

hotfix — порядковый номер хотфикса. Часто бывает, что все изменения в версии связаны с исправлением багов, а не с добавлением функционала. В этом случае изменяется номер хотфикса. Очень часто, такая версия отдается в виде патча для обновления с предыдущей версии.

Четвертая цифра это порядковый номер билда. Номера билдов сквозные и не зависят от версий. Это необходимо для того чтобы иметь возможность воспроизвести баг, проявляющийся у клиента точно на той версии, какая установлена у него. Чаще всего используют последовательный номер или номер ревизии из VCS.

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

понедельник, марта 01, 2010

Bug theory - Initialization flow bug

С простыми багами вроде покончено. Перейдем к более сложным.

Initialization flow bug

Симптомы:

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

Критические места:

Инициализация модулей, добавление новых зависимостей, изменения порядка инициализации.

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

Профилактика:

Локализовать инициализацию в одно месте, практиковать Dependency injection, писать интеграционные тесты, при добавлении зависимости анализировать порядок инициализации для разных случаев.