![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Организация процесса распространения и установки runtime-пакетов
Суслик © (2005-08-19 15:31:00)Тема 1
Мы занимаемся разработкой бухгалтерской системы. Разные элементы системы находятся в отдельных пакетах. Экранные формы и печатные формы расположены в пакетах, которые подгружаются с помощью функции LoadPackage в момент запуска программы.
В целях упрощения поддержки системы у заказчиков запуск производится из сетевого каталога. В этом же каталоге расположены все требуемые BPL.
Требуется организовать возможность "горячей" подмены элементов системы, т.е. без того, чтобы заставлять всех пользователей закрывать приложение. Ясное дело, что не все элементы системы могут быть подменены таким образом. Наиболее критические части будут требовать безусловного выхода пользователей из приложения. Но есть некоторые некритичные элементы, которые таким образом подменять можно. Например, печатные формы.
Я предполагаю организовать это так.
Например, нужно заменить печать платежного поручения. Печать реализована в пакете pp_print.bpl.
Программа при запуске находит все пакеты с именем pp_print_xx.bpl (хх - номер версии) и загружает пакет с наибольшим номером xx. Например, pp_print_07.bpl. При необходимости обновления пакета, в сетевой каталог программы записывается pp_print_08.bpl. При каждой печати платежного поручения программа проверяет не появился ли в каталоге пакет pp_print_xx.bpl с большим номером, чем тот, который загружен. Если появился, то старый пакет выгружается, а новый загружается и используется в печати. В итоге через некоторое время (скорее всего к концу дня) все устаревшие пакеты будут выгружены из программ и их можно будет удалить.
ВОПРОС 1:Интересует экспертная оценка предполагаемого алгоритма "горячего" обновления пакетов, изложенная выше.
Тема 2
При наличии большого количества пакетов (сейчас порядка 100) и большого объема разноплановой работы бывает сложно уследить, за тем, какие пакеты должны быть заменены у заказчика при следующем обновлении.
Также пакеты бывает сильно друг с другом взаимосвязаны. Например, обновление пакетов с прототипами (предками) плугинов иногда требуют обновления самих полугинов.
ВОПРОС 2:Хотелось бы услышать опыт автоматизированного анализа исходного кода на предмет построения списка тех пакетов, которые должны быть обновлены.
Игорь Шевченко (2005-08-22 15:45:00) [1]Суслик © (22.08.05 14:31) [37]
Там просто обновляется - файлы обновления помещаются во временную папку, запрашивается перезагрузка, во время перезагрузки файлы перемещаются в нужное место.
Суслик (2005-08-22 14:31:00) [2]
> [36] alex_*** (22.08.05 14:30)
> вот если б сделали запуск приложения с локальной машины+проверка
> текущей версии где-ть в БД или на сетевой папке, то и проблемы
> бы не было.
Такая идея была :) Тоже обдумываю.
Суслик (2005-08-22 14:31:00) [3]
> [35] Игорь Шевченко © (22.08.05 13:12)
Игорь, ну вот я испросил [18] что изучать, чтобы сделать обновление как у windows.
alex_*** (2005-08-22 14:30:00) [4]вот если б сделали запуск приложения с локальной машины+проверка текущей версии где-ть в БД или на сетевой папке, то и проблемы бы не было.
Игорь Шевченко (2005-08-22 13:12:00) [5]
> В действительности часто обновления нужно делать именно
> в рабочее время. Пример. Найден баг (ну кто без этого).
> Редко, но бывает, особенно в редкоиспользуемых блоках. Нужно
> срочно провести обновление. Конец квартала, пожар. Нужно
> сделать срочно.
А такой вопрос - как Windows обновляется ? :) Там багов находят поболе...ищущих всяко больше, чем у твоей программы.
Суслик (2005-08-22 13:08:00) [6]
> [33] Leonid Troyanovsky © (19.08.05 20:59)
> А почему ты думаешь о нас плохо?
Больше не буду :)
> К примеру, разберем случай когда некто в конце периода
> стремится завершить оный с наименьшими для себя потерями.
> А тут, как не кстати, очередные изменения.
> Ну, а может некто с оными багами свыкся, что ж ему все менять
> по-новой?
Я сильно старался изложить свою позицию, но видно не до конца ясно это у меня получилось. Вот смотри, есть некритичные для всей системы блоки. Которые можно менять без ущерба. Как это делать.
То что здесь есть административные проблемы сомнения не вызывает, но я же и пытаюсь из сгладить, т.е. сделать не такими достающими. :)
Leonid Troyanovsky (2005-08-19 20:59:00) [7]
> Суслик © (19.08.05 17:00) [15]
> Не понимаю, почему есть такое желание поязвить. :)
> Есть система, работает 4й год. Есть определенный опыт поддержки.
> Поменять можно, но тогда в службе поддержки нужно еще пару
> человек. :)
А почему ты думаешь о нас плохо?
К примеру, разберем случай когда некто в конце периода
стремится завершить оный с наименьшими для себя потерями.
А тут, как не кстати, очередные изменения.
Ну, а может некто с оными багами свыкся, что ж ему все менять
по-новой?
Т.е., проблема эта чисто административная.
Не хотят люди пользовать новое, замучиешься ты убивать
старые версии.
--
Regards, LVT.
Внук (2005-08-19 19:55:00) [8]У нас ситуация похожая, мы делаем, как написал Petr V. Abramov © (19.08.05 18:11) [24]
Lamer@fools.ua (2005-08-19 18:47:00) [9]>> Petr V. Abramov © (19.08.05 18:19) [27]
> Обычным образом, в проводнике правая мышь -> Rename
[offtopic]
Да Вы, батенька, гурман, однако. Две мыши: правая, левая :o)
[/offtopic]
Суслик (2005-08-19 18:45:00) [10]
> [29] Petr V. Abramov © (19.08.05 18:42)
Я понял, что надого, да и пятница уже. :)
Если будешь на ближайшей сходе - ставлю. :)
Спасибо за ответы. Надеюсь еще кто-то объявится с опытом :)
Petr V. Abramov (2005-08-19 18:42:00) [11]> Суслик © (19.08.05 18:25) [28]
> Это как?
Это надолго. :) Ставь пиво, расскажу идеологию, а ЮЗ - реализацию :)
Суслик (2005-08-19 18:25:00) [12]
> [27] Petr V. Abramov © (19.08.05 18:19)
> > Суслик © (19.08.05 18:12) [26]
> > А как?
> Обычным образом, в проводнике правая мышь -> Rename
Вот это да, и правда переименовываются - что-то даже не подумал попробовать :)
> Была предусмотрена возможность безопасной выгрузки любой
> DLL пользователем.
Это как?
Petr V. Abramov (2005-08-19 18:19:00) [13]> Суслик © (19.08.05 18:12) [26]
> А как?
Обычным образом, в проводнике правая мышь -> Rename
> Вообще вопрос был про опыт :) Может кто уже сталкивался с подобной задачей.
Опыт был с плагинами на DLL. Проектировали так, чтоб они друг от друга не зависели (но зависели от нескольких BPL, которые редко менялись). Была предусмотрена возможность безопасной выгрузки любой DLL пользователем.
Суслик (2005-08-19 18:12:00) [14]
> [24] Petr V. Abramov © (19.08.05 18:11)
> Под NT-системами можно переименовать старый, пока он загружен,
> и положить на место новый. Криво, конечно, но метод
А как?
Суслик (2005-08-19 18:11:00) [15]
> [23] Petr V. Abramov © (19.08.05 18:09)
Да это я понимаю, что можно так сделать.
Вообще вопрос был про опыт :) Может кто уже сталкивался с подобной задачей.
Petr V. Abramov (2005-08-19 18:11:00) [16]Под NT-системами можно переименовать старый, пока он загружен, и положить на место новый. Криво, конечно, но метод
Petr V. Abramov (2005-08-19 18:09:00) [17]Список зависимых пакетов там и так есть
PPackageInfoHeader = ^TPackageInfoHeader;
TPackageInfoHeader = packed record
Flags: Cardinal;
RequiresCount: Integer;
{Requires: array[0..9999] of TPkgName;
ContainsCount: Integer;
Contains: array[0..9999] of TUnitName;}
end;
function PackageInfoTable(Module: HMODULE): PPackageInfoHeader;
(цитата из SysUtils)
Суслик (2005-08-19 17:51:00) [18]
> [19] Юрий Зотов © (19.08.05 17:25)
>
> ... но что будет если какой-нибудь шибко умный юзер переименует файл
> пакета (типа "а на фига тут семерка, я пятерку хочу")?
У них нет прав на правку сетевого каталога.
> ИМХО, лучше либо
> заложить в пакет предопределенную функцию, возвращающую
> его версию, либо, как оно и положено, брать версию прямо
> из ресурсов пакета.
Это идея хорошая. Но она не решает проблему того, что заменить файл с пакетом я не могу, т.к. он занят приложением (загружен). Т.е. я должен новый пакет записывать под НОВЫМ именем.
> Тема 2.
>
> Аналогично - либо закладываем в пакет функцию, возвращающую
> список взаимосвязанных пакетов вместе с их нужными версиями,
> либо забабахиваем этот список в ресурсы пакета (что можно
> сделать и прямо в IDE).
Ты немного не о том, о чем я спрашивал. Вот представь. У тебя есть - 100 каталогов под каждый пакет. Что-то менялось. Задача по каталогу сделать сборку дистрибуции. Т.е. собрать все пааеты, и зависящие от них которые менялись. Тут нужен очевидно анализ исходного кода. Например, по дате изменения и как-то еще.
alex_*** (2005-08-19 17:31:00) [19][19]- на мой взгляд слишком сложно для разработчиков. Путаться будут, забывать о новых/ненужных связках.
alex_*** (2005-08-19 17:29:00) [20]отбранчить. папку рядом завести, куда ложить сборку с патчем. Кому срочно надо юзать без бага, я думаю таких немного, пусть подключается к приложению в этой папке. Когда уляжется шум, очистить её и обновить основную версию