![]() |
| ||
|
|
Новости |
Поиск |
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-19 17:25:00) [21]> Суслик © (19.08.05 15:31)
Тема 1.
Алгоритм замены, вроде как, нормальный, но что будет если какой-нибудь шибко умный юзер переименует файл пакета (типа "а на фига тут семерка, я пятерку хочу")? ИМХО, лучше либо заложить в пакет предопределенную функцию, возвращающую его версию, либо, как оно и положено, брать версию прямо из ресурсов пакета.
Тема 2.
Аналогично - либо закладываем в пакет функцию, возвращающую список взаимосвязанных пакетов вместе с их нужными версиями, либо забабахиваем этот список в ресурсы пакета (что можно сделать и прямо в IDE).
=============================================
В итоге приходим к решению, когда каждый пакет сам про себя все рассказывает и юзер нагадить никак не может (разве что каким-нить Resource Hacker'ом влезет, но это уже явная паранойя). ИМХО, вполне надежно.
Суслик (2005-08-19 17:12:00) [22]1) Я думал над тем, чтобы сделать такое же обновление как в windows. Но есть пункт 2) (см. ниже).
Но все за спрошу, т.к. может оказаться полезным.
Вопрос, куда копать? Что это за система? Или свое что-то нужно писать.
> Т.е., в если в вашей конторе по ночам никто не
> трудится, то - это самое время для апдейтов.
В действительности часто обновления нужно делать именно в рабочее время. Пример. Найден баг (ну кто без этого). Редко, но бывает, особенно в редкоиспользуемых блоках. Нужно срочно провести обновление. Конец квартала, пожар. Нужно сделать срочно. До той поры, пока было все в одном exe приходилось всех выгонять и делать обновление. Теперь хочется, ПОНИМАЯ конкретную ситуацию, понимая, что обновляешь некритичный ДЛЯ СИСТЕМЫ ВЦЕЛОМ блок выполнить "горячее" обновление какой-то ее части.
Leonid Troyanovsky (2005-08-19 17:08:00) [23]
> Суслик © (19.08.05 17:01) [16]
>
> > [14] Leonid Troyanovsky © (19.08.05 16:58)
>
> Вторую :)
Ну, тут нам хороший пример подают ребята(девчонки)из Ричмонда.
Кажный день(при нужде), когда время 18:00 по-ихнему,
они делают очередной релиз жизненно важных библов
(да и кучи екзе, составляющих ядро Windows, и рассылают его по
всему свету, тестировщикам, видимо).
Надеюсь, идея ясна?
Т.е., в если в вашей конторе по ночам никто не
трудится, то - это самое время для апдейтов.
--
Regards, LVT.
Суслик (2005-08-19 17:01:00) [24]
> [14] Leonid Troyanovsky © (19.08.05 16:58)
Вторую :)
Суслик (2005-08-19 17:00:00) [25]
> [13] Leonid Troyanovsky © (19.08.05 16:57)
Не понимаю, почему есть такое желание поязвить. :)
Есть система, работает 4й год. Есть определенный опыт поддержки. Поменять можно, но тогда в службе поддержки нужно еще пару человек. :)
Я допускаю, что есть другие решения. Был бы рад услышать о чем-то конкретном :)
Leonid Troyanovsky (2005-08-19 16:58:00) [26]
> Суслик © (19.08.05 16:55) [12]
> > [10] Leonid Troyanovsky © (19.08.05 16:51)
> Прости, не понял :)
Первую часть или вторую?
--
Regards, LVT.
Leonid Troyanovsky (2005-08-19 16:57:00) [27]
> Суслик © (19.08.05 16:54) [11]
> Прошу, не надо советов по административному устройству нашей
> работы. Изменить что-то в этом крайне сложно.
Как наше хозяйство из убыточного сделать прибыльным,
ничего в оном не меняя? (Салтыков-Щедрин, кажись).
--
Regards, LVT.
Суслик (2005-08-19 16:55:00) [28]
> [10] Leonid Troyanovsky © (19.08.05 16:51)
Прости, не понял :)
Суслик (2005-08-19 16:54:00) [29]
> [9] Игорь Шевченко © (19.08.05 16:44)
На самом деле проблема в том, что пользователей много до 200 одновременно. Часто бывает так - систему запустят, комп залочат и идут обедать. Когда случаются обновления в критические дни (перед концом кварталов) людей вообще сложно прерывать. Подмена некритических блоков была бы очень кстати.
Прошу, не надо советов по административному устройству нашей работы. Изменить что-то в этом крайне сложно.
Leonid Troyanovsky (2005-08-19 16:51:00) [30]
> Игорь Шевченко © (19.08.05 16:44) [9]
>
> > Написать нормальный дистрибутив с проверкой версий и пускать
> > его, выгнав всех пользователей
> Я тоже склоняюсь к такому мнению.
Если географический регион компактен,
то сие могутно деяти аки тать в ночи.
--
Regards, LVT.
Игорь Шевченко (2005-08-19 16:44:00) [31]
> Написать нормальный дистрибутив с проверкой версий и пускать
> его, выгнав всех пользователей
Я тоже склоняюсь к такому мнению.
alex_*** (2005-08-19 16:41:00) [32][5] снимать CRC?
Суслик (2005-08-19 16:12:00) [33]
> [5] КаПиБаРа © (19.08.05 16:07)
> А может проще содержимое/размер самих пакетов анализировать?
А подробнее?
alex_*** (2005-08-19 16:08:00) [34]чем проще система, тем надежнее работает. а то будете еще разрабатывать и поддерживать систему для контроля и обновления версий, и глюки будете ловить там и там
КаПиБаРа (2005-08-19 16:07:00) [35]А может проще содержимое/размер самих пакетов анализировать?
Суслик (2005-08-19 16:06:00) [36]
> [3] alex_*** (19.08.05 15:54)
> когда есть возможность сломаться, то обязательно сломается
> ;)
А этой теме посвещена вторая часть моего вопроса :)
Об автоматизированных средствах анализа.
alex_*** (2005-08-19 15:54:00) [37]когда есть возможность сломаться, то обязательно сломается ;)
Суслик (2005-08-19 15:53:00) [38]
> частичное обновление может привести к краху системы, на
> мой взгляд. Обновим пакет, а форма что его юзает не обновится
> - получаем по башке
Я указал, что такое обновление возможно только в определенных случаях, которые не приводят к краху. Т.е. эта возможность исключается.
alex_*** (2005-08-19 15:51:00) [39]частичное обновление может привести к краху системы, на мой взгляд. Обновим пакет, а форма что его юзает не обновится - получаем по башке. Написать нормальный дистрибутив с проверкой версий и пускать его, выгнав всех пользователей. А то сами запутаетесь в версиях, системе названий пакетов.