Организация процесса распространения и установки runtime-пакетов

← →
Суслик © (2005-08-19 15:31) [0]

Тема 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: Хотелось бы услышать опыт автоматизированного анализа исходного кода на предмет построения списка тех пакетов, которые должны быть обновлены.

← →
alex_*** (2005-08-19 15:51) [1]

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

← →
Суслик © (2005-08-19 15:53) [2]

> частичное обновление может привести к краху системы, на
> мой взгляд. Обновим пакет, а форма что его юзает не обновится
> - получаем по башке

Я указал, что такое обновление возможно только в определенных случаях, которые не приводят к краху. Т.е. эта возможность исключается.

← →
alex_*** (2005-08-19 15:54) [3]

когда есть возможность сломаться, то обязательно сломается ;)

← →
Суслик © (2005-08-19 16:06) [4]

> [3] alex_*** (19.08.05 15:54)
> когда есть возможность сломаться, то обязательно сломается
> ;)

А этой теме посвещена вторая часть моего вопроса :)
Об автоматизированных средствах анализа.

← →
КаПиБаРа © (2005-08-19 16:07) [5]

А может проще содержимое/размер самих пакетов анализировать?

← →
alex_*** (2005-08-19 16:08) [6]

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

← →
Суслик © (2005-08-19 16:12) [7]

> [5] КаПиБаРа © (19.08.05 16:07)
> А может проще содержимое/размер самих пакетов анализировать?

А подробнее?

← →
alex_*** (2005-08-19 16:41) [8]

[5] снимать CRC?

← →
Игорь Шевченко © (2005-08-19 16:44) [9]

> Написать нормальный дистрибутив с проверкой версий и пускать
> его, выгнав всех пользователей

Я тоже склоняюсь к такому мнению.

← →
Leonid Troyanovsky © (2005-08-19 16:51) [10]

> Игорь Шевченко © (19.08.05 16:44) [9]
>
> > Написать нормальный дистрибутив с проверкой версий и пускать

> > его, выгнав всех пользователей

> Я тоже склоняюсь к такому мнению.

Если географический регион компактен,
то сие могутно деяти аки тать в ночи.

--
Regards, LVT.

← →
Суслик © (2005-08-19 16:54) [11]

> [9] Игорь Шевченко © (19.08.05 16:44)

На самом деле проблема в том, что пользователей много до 200 одновременно. Часто бывает так - систему запустят, комп залочат и идут обедать. Когда случаются обновления в критические дни (перед концом кварталов) людей вообще сложно прерывать. Подмена некритических блоков была бы очень кстати.

Прошу, не надо советов по административному устройству нашей работы. Изменить что-то в этом крайне сложно.

← →
Суслик © (2005-08-19 16:55) [12]

> [10] Leonid Troyanovsky © (19.08.05 16:51)

Прости, не понял :)

← →
Leonid Troyanovsky © (2005-08-19 16:57) [13]

> Суслик © (19.08.05 16:54) [11]

> Прошу, не надо советов по административному устройству нашей
> работы. Изменить что-то в этом крайне сложно.

Как наше хозяйство из убыточного сделать прибыльным,
ничего в оном не меняя? (Салтыков-Щедрин, кажись).

--
Regards, LVT.

← →
Leonid Troyanovsky © (2005-08-19 16:58) [14]

> Суслик © (19.08.05 16:55) [12]

> > [10] Leonid Troyanovsky © (19.08.05 16:51)

> Прости, не понял :)

Первую часть или вторую?

--
Regards, LVT.

← →
Суслик © (2005-08-19 17:00) [15]

> [13] Leonid Troyanovsky © (19.08.05 16:57)

Не понимаю, почему есть такое желание поязвить. :)
Есть система, работает 4й год. Есть определенный опыт поддержки. Поменять можно, но тогда в службе поддержки нужно еще пару человек. :)

Я допускаю, что есть другие решения. Был бы рад услышать о чем-то конкретном :)

← →
Суслик © (2005-08-19 17:01) [16]

> [14] Leonid Troyanovsky © (19.08.05 16:58)

Вторую :)

← →
Leonid Troyanovsky © (2005-08-19 17:08) [17]

> Суслик © (19.08.05 17:01) [16]
>
> > [14] Leonid Troyanovsky © (19.08.05 16:58)
>
> Вторую :)

Ну, тут нам хороший пример подают ребята(девчонки)из Ричмонда.
Кажный день(при нужде), когда время 18:00 по-ихнему,
они делают очередной релиз жизненно важных библов
(да и кучи екзе, составляющих ядро Windows, и рассылают его по
всему свету, тестировщикам, видимо).
Надеюсь, идея ясна?

Т.е., в если в вашей конторе по ночам никто не
трудится, то - это самое время для апдейтов.

--
Regards, LVT.

← →
Суслик © (2005-08-19 17:12) [18]

1) Я думал над тем, чтобы сделать такое же обновление как в windows. Но есть пункт 2) (см. ниже).

Но все за спрошу, т.к. может оказаться полезным.

Вопрос, куда копать? Что это за система? Или свое что-то нужно писать.

> Т.е., в если в вашей конторе по ночам никто не
> трудится, то - это самое время для апдейтов.

В действительности часто обновления нужно делать именно в рабочее время. Пример. Найден баг (ну кто без этого). Редко, но бывает, особенно в редкоиспользуемых блоках. Нужно срочно провести обновление. Конец квартала, пожар. Нужно сделать срочно. До той поры, пока было все в одном exe приходилось всех выгонять и делать обновление. Теперь хочется, ПОНИМАЯ конкретную ситуацию, понимая, что обновляешь некритичный ДЛЯ СИСТЕМЫ ВЦЕЛОМ блок выполнить "горячее" обновление какой-то ее части.

← →
Юрий Зотов © (2005-08-19 17:25) [19]

> Суслик © (19.08.05 15:31)

Тема 1.

Алгоритм замены, вроде как, нормальный, но что будет если какой-нибудь шибко умный юзер переименует файл пакета (типа "а на фига тут семерка, я пятерку хочу")? ИМХО, лучше либо заложить в пакет предопределенную функцию, возвращающую его версию, либо, как оно и положено, брать версию прямо из ресурсов пакета.

Тема 2.

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

=============================================

В итоге приходим к решению, когда каждый пакет сам про себя все рассказывает и юзер нагадить никак не может (разве что каким-нить Resource Hacker"ом влезет, но это уже явная паранойя). ИМХО, вполне надежно.

← →
alex_*** (2005-08-19 17:29) [20]

отбранчить. папку рядом завести, куда ложить сборку с патчем. Кому срочно надо юзать без бага, я думаю таких немного, пусть подключается к приложению в этой папке. Когда уляжется шум, очистить её и обновить основную версию

← →
alex_*** (2005-08-19 17:31) [21]

[19]- на мой взгляд слишком сложно для разработчиков. Путаться будут, забывать о новых/ненужных связках.

← →
Суслик © (2005-08-19 17:51) [22]

> [19] Юрий Зотов © (19.08.05 17:25)

>
> ... но что будет если какой-нибудь шибко умный юзер переименует файл
> пакета (типа "а на фига тут семерка, я пятерку хочу")?

У них нет прав на правку сетевого каталога.

> ИМХО, лучше либо
> заложить в пакет предопределенную функцию, возвращающую
> его версию, либо, как оно и положено, брать версию прямо
> из ресурсов пакета.

Это идея хорошая. Но она не решает проблему того, что заменить файл с пакетом я не могу, т.к. он занят приложением (загружен). Т.е. я должен новый пакет записывать под НОВЫМ именем.

> Тема 2.
>
> Аналогично - либо закладываем в пакет функцию, возвращающую
> список взаимосвязанных пакетов вместе с их нужными версиями,
> либо забабахиваем этот список в ресурсы пакета (что можно
> сделать и прямо в IDE).

Ты немного не о том, о чем я спрашивал. Вот представь. У тебя есть - 100 каталогов под каждый пакет. Что-то менялось. Задача по каталогу сделать сборку дистрибуции. Т.е. собрать все пааеты, и зависящие от них которые менялись. Тут нужен очевидно анализ исходного кода. Например, по дате изменения и как-то еще.

← →
Petr V. Abramov © (2005-08-19 18:09) [23]

Список зависимых пакетов там и так есть

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)

← →
Petr V. Abramov © (2005-08-19 18:11) [24]

Под NT-системами можно переименовать старый, пока он загружен, и положить на место новый. Криво, конечно, но метод

← →
Суслик © (2005-08-19 18:11) [25]

> [23] Petr V. Abramov © (19.08.05 18:09)

Да это я понимаю, что можно так сделать.

Вообще вопрос был про опыт :) Может кто уже сталкивался с подобной задачей.

← →
Суслик © (2005-08-19 18:12) [26]

> [24] Petr V. Abramov © (19.08.05 18:11)
> Под NT-системами можно переименовать старый, пока он загружен,
> и положить на место новый. Криво, конечно, но метод

А как?

← →
Petr V. Abramov © (2005-08-19 18:19) [27]

> Суслик © (19.08.05 18:12) [26]
> А как?
Обычным образом, в проводнике правая мышь -> Rename

> Вообще вопрос был про опыт :) Может кто уже сталкивался с подобной задачей.
Опыт был с плагинами на DLL. Проектировали так, чтоб они друг от друга не зависели (но зависели от нескольких BPL, которые редко менялись). Была предусмотрена возможность безопасной выгрузки любой DLL пользователем.

> [27] Petr V. Abramov © (19.08.05 18:19)
> > Суслик © (19.08.05 18:12) [26]
> > А как?
> Обычным образом, в проводнике правая мышь -> Rename

Вот это да, и правда переименовываются - что-то даже не подумал попробовать :)

> Была предусмотрена возможность безопасной выгрузки любой
> DLL пользователем.

Это как?

> [29] Petr V. Abramov © (19.08.05 18:42)

Я понял, что надого, да и пятница уже. :)
Если будешь на ближайшей сходе - ставлю. :)

Спасибо за ответы. Надеюсь еще кто-то объявится с опытом :)

>>Petr V. Abramov © (19.08.05 18:19) [27]

>Обычным образом, в проводнике правая мышь -> Rename

[offtopic]
Да Вы, батенька, гурман, однако. Две мыши: правая, левая :o)
[/offtopic]

> Суслик © (19.08.05 17:00) [15]

> Не понимаю, почему есть такое желание поязвить. :)
> Есть система, работает 4й год. Есть определенный опыт поддержки.
> Поменять можно, но тогда в службе поддержки нужно еще пару
> человек. :)

А почему ты думаешь о нас плохо?

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

Т.е., проблема эта чисто административная.
Не хотят люди пользовать новое, замучиешься ты убивать
старые версии.

--
Regards, LVT.

> [33] Leonid Troyanovsky © (19.08.05 20:59)

> А почему ты думаешь о нас плохо?

Больше не буду :)

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

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

То что здесь есть административные проблемы сомнения не вызывает, но я же и пытаюсь из сгладить, т.е. сделать не такими достающими. :)

> В действительности часто обновления нужно делать именно
> в рабочее время. Пример. Найден баг (ну кто без этого).
> Редко, но бывает, особенно в редкоиспользуемых блоках. Нужно
> срочно провести обновление. Конец квартала, пожар. Нужно
> сделать срочно.

А такой вопрос - как Windows обновляется ? :) Там багов находят поболе...ищущих всяко больше, чем у твоей программы.

← →
alex_*** (2005-08-22 14:30) [36]

вот если б сделали запуск приложения с локальной машины+проверка текущей версии где-ть в БД или на сетевой папке, то и проблемы бы не было.

> [35] Игорь Шевченко © (22.08.05 13:12)

Игорь, ну вот я испросил [18] что изучать, чтобы сделать обновление как у windows.

> [36] alex_*** (22.08.05 14:30)

> вот если б сделали запуск приложения с локальной машины+проверка
> текущей версии где-ть в БД или на сетевой папке, то и проблемы
> бы не было.

Такая идея была :) Тоже обдумываю.

Суслик © (22.08.05 14:31) [37]

Там просто обновляется - файлы обновления помещаются во временную папку, запрашивается перезагрузка, во время перезагрузки файлы перемещаются в нужное место.

Организация процесса распространения и установки runtime-пакетов Найти похожие ветки