1.1.1.1 Предусловия:
Весь дальнейший текст написан в предположении, что у Вас версия биллинга не позднее 15.10.2008. Для апдейтов более ранних версий данный порядок неприменим.
Политика апдейтов и коммитов определяет правила, которым должны следовать разработчики и администраторы инсталляций для обновления и применения патчей к инсталляции биллинга
Различаются два вида поставок биллинга
- Релизы (определяются трехзначным номером, периодичность - приблизительно раз в год)
- Текущие обновления: отражают основную ветвь svn.
На практике релиз - это просто слепок текущего обновления за какое-то число, завернутый в инсталляцию и прошедший через процедуру тестирования. Релизы ставятся при новых инсталляциях, текущие обновления раздаются пользователям, подписанным на source-connection.
У клиента как правило релиз и набор апдейтов, а также набор своих собственных кастомизаций биллинга (отчеты и TCL-хендлера). Мы держим ядро биллинга для всех одинаковое, а набор пользовательстких интерфейсов и отчетов у разных клиентов разный. Как правило они описанны в подиректории billing-clients/<ClientIdentifier> в svn с точностью и степени корректности, зависящей от проекта. Так как клиенты в теории могут писать отчеты и Tcl-хандлера сами то на эту информацию в точности полагаться нельзя
1.1.1.1 Краткое содержание:
Версия в trunk стараемся держать корректной. Она должна работать не только с последней версией БД, но с версиями БД начиная с
ревизии - last_supported_revision. Значение last_supported_revision должно обнвляться в svn в файле etc/README. Кстати - а что такое "версия БД" - это версия svn ревизии.
Исключения составляют обновления локализации (они будут помечены как .1) - инит скрипты там обязательно нужно запускать, при этом версия БД не обновляется.
Дайвайте определим следующие версионные значения
- last_revision - значение ревиззии БД. Храниться в properties. Может проверяться из кода (в С++ - Servlet_impl::getLastRevision(), про Tcl надо вписать если понадобиться
- last_supported_revision - значение (справочное). В рантайм недоступно. (Внесем если понадобится) Во время ращработки см. значение в svn etc/README
- current_revision - текущая ревизия кода. значение (справочное). В рантайм доступно как номер версии на транице Хелпа "О программе". Из C кода как BillingCompilationInfo::svnversion. (В Tcl сейчас нет) Во время разработки см. просто номер ревизии svn
Развитие: мы ведем работу по том, что бы в будущем разработать набор тестов которые автоматически применяются к собранной системе и проверяют ее (естественно огранниченно) на корректность, что бы помечать транки, которые прошли тесты, как тестируемые. На сейчас такой системы нет, последняя версия из транка всегда считается корректной. Заметим что так как тестирование всех конфигураций в принципе невозможно, то проверять патч на применимость к данной конфигурации перед апдейтом нужно все-равно.
1.1.1.1.1 Обновление
Обновление включает в себя
- изменение структуры БД
- изменения содержания метаинформации (хандлеры, отчеты)
- изменения программного кода ядра
Когда мы меняем что-то в программе, то мы должны также выпустить и соответствующее обновление, а также применимость его обновления (которое выполняется администратором согласно стандартной инструкции)
1.1.1.1.1 Подробности для программистов:
При доработке новых возможностей помним следующее
- Программа должна продолжать работать на старой БД (версии last_supported_revision и более), поэтому если мы меняем структуру БД, то перед использованием дополнительных полей проверяем версию БД. (Как правило - просто ставим старый блок кола в 'if', а потом его удаляем когда увеличиваем last_supported_revision)
- Если мы поменяли БД, то нам надо
- модифицировать init-script, что бы у нас создавадлась новая БД с вашими изменениями
- подготовить патчи к БД, которые должны будут применяться на существующих инсталляциях.
Патчи храним- в период до формальной ревизии 2.10 - в директории sql/Oracle/patches/2.0.9-2.0.10/DD_MM_YYYY (где DD_MM_YYYY - текущее число)
- в период после формальной ревизии 2.10 - в директории sql/Oracle/patches/2.0.10-2.2/YYYY_MM_DD
- пометить в патче БД новую ревизию. Стандартный PL/SQL код для этого выглядит следующим образом
declare np NUMBER(10); begin select count(*) into np from properties where name='last_revision'; if np = 0 then insert into properties(name,value) values('last_revision','14253'); else update properties set value='14253' where name='last_revision'; end if; end;
- Если мы поменяли Хандлера то нам надо
- Тоже проверить в них версию БД
- Добавить в патч и в init.sql соответствующие изменеие в таблицах vr_menu_items и tcl_handlers_auth
- Пишем в документации о необходимости переустановитть хандлера
Также учитываем, что возможна ситуация, когда один и тот=же патч применяется два раза (случайно), эту ситуацию надо обрабатывать и тестировать перед коммитом патча
Некоторую особенность составляют обновления локализации
Тут следующая проблема
- старая программа при обнвлениях локализации перестает рабюотать всегда (перепутывается соответствия между сообщениями и кодами сообщений)
- как правило, при обновлениях локализации, никаких других действий над БД, кроме обновления словарей, не производится
Поэтому если организация обновляет версию программы, то она обязательно должна применить и сопряженные правки БД последней локализации. Эти правки таблиц локализации никак не влияют на значения версий.
