Наука об установке

Question

У меня минимальная подверженность RPM, механике установки Windows и WIX. Тем не менее, я заинтересован в создании кроссплатформенного установщика (Linux, Windows), который поддерживает обновление и понижение версии (версии и исправления) моего собственного продукта. Я не верю, что к этой теме нужно подходить легко; Я хотел бы изучить науку об искусстве (или искусство науки). Если мне это удастся, и я создам минимально успешный инструмент установки, он будет иметь следующие функции:

• не зависит от инструмента для платформы (например, установщика Windows).
• читает XML или декларативный синтаксис для выполнения требований установки.
• пытается свести к минимуму шаги по обновлению или понижению версии одного из моих продуктов (вместо того, чтобы требовать полной деинсталляции и переустановки).
• не требует знания промежуточных версий продукта, чтобы перейти на другую версию (то есть можно обновить один из моих продуктов с версии 1 до версии 3, не проходя через версию 2).

Я убежден, что «ключ» к достижению этой цели заключается в том, чтобы рассматривать версии как проблему «точка А в точку Б», которая подразумевает, что А и В описываются двумя документами «версии» XML, которые содержат информацию о все части и действия (файлы или особенности платформы, такие как записи реестра). Мой инструмент установщика "объединит" или сравнит два документа и определит минимальный набор изменений для преобразования А в В. В какой-то степени я считаю, что это именно то, что делает установщик Windows.

Конечно, есть и другие сложности, но в этом смысл этого поста. Где "библия" информации по этой теме? Помните, я хочу создать свой собственный установщик, а не использовать платформу для конкретной платформы. Для тех, кто заботится, мои продукты обычно написаны на C ++ или C #.

Или, возможно, мне следует изучить что-то вроде Steam , которое является кроссплатформенным и имеет «автоматические обновления игры» как часть его возможностей. В моем случае проблема онлайн-развертывания уже решена. Это только последний этап установки, который я изучаю. Использует ли Steam собственные установщики (такие как MSI)? Если да, то это не то, что я ищу.

Короче говоря, по какому пути я должен идти, чтобы стать несколько компетентным в науке по этой теме?

Answer 1

Я не эксперт, и другие могут дать вам лучшие ответы, но ...

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

Еще одно соображение заключается в том, что возможность понижения может повлечь за собой огромные сложности в зависимости от вашего продукта - придется ли понижать качество баз данных схем / форматов файлов / ??? Короче говоря, каждая версия вашего приложения должна быть полностью совместимой с прямой и обратной совместимостью (или, по крайней мере, терпеть неудачу). Также рассмотрите сценарий, в котором V1 вашего приложения хранит настройки в файле. V2 приходит и добавляет больше настроек. Вы переходите на V1 - что он должен делать при изменении настроек? сохранить настройки V2? сбросить их? Меняют ли некоторые настройки V2 влияние / значение настроек V1? Эти решения будут приниматься вашим приложением или вашим установщиком?

Во всяком случае, все это в стороне, я бы сказал, вам нужно, по крайней мере:

• Центральный сервер / ферма с полными файлами для каждой версии вашего приложения и некоторыми API / веб-сервисами, которые позволяют установщику получать файлы / наборы файлов / ??? в зависимости от обстоятельств (вы можете связать это с системой контроля версий, например, svn)
• Какой-то способ указать желаемое состояние системы после установки в зависимости от среды (Подумайте об установочных путях - /usr/??? - следует ли сопоставлять C:\Users\??? или C:\Program Files в Windows? Также не забывайте это может быть 64-битная машина, поэтому это может быть C:\Program Files (x86).
• Очень умный установщик, написанный для нескольких платформ с максимально возможным повторным использованием кода (Java, Mono, ???)

Установщик должен сделать (просто):

• Определите желаемую версию продукта.
• Загрузите / прочитайте соответствующий манифест.
• Сравните желаемую ситуацию с текущей ситуацией (примечание: что в настоящее время находится в локальной системе, а НЕ то, что должно быть в системе в соответствии с манифестом текущей версии)
• Создайте список шагов для их согласования с учетом любых зависимостей (невозможно установить права доступа к файлу до его копирования). Вы можете использовать контрольные суммы / хэширование / аналогичные для сравнения существующих файлов с желаемыми файлами - таким образом, загружая только те файлы, которые действительно требуются.
• Возможно сделать полное резервное копирование
• Загрузка / распаковка необходимых файлов.
• Загрузка / распаковка сторонних зависимостей - позже .Net Framework Version / Similar
• Выполняйте этапы установки атомарным способом, насколько это возможно (по крайней мере, ведите учет шагов, предпринятых, чтобы их можно было отменить)
• Потенциально применить любые изменения, связанные с переходом от версии (повышение / понижение уровня качества, файлы конфигурации и т. Д.)
• проверить установку как можно больше (контрольные суммы снова)

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

Техника, которую я использовал в Windows, заключается в том, что сам исполняемый файл установщика является всего лишь оболочкой с некоторыми интерфейсами, которая динамически загружает фактический установщик во время выполнения - таким образом я могу перемещать файлы о / выгрузить / перезагрузить сборки и т. Д. внутри фиксированного процесса, который почти никогда не меняется.

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