MSI diff на пакеты для создания патчей

Я смотрю, какие лучшие варианты для создания патчей для наших клиентов. Они не хотят, чтобы установщик с полной версией выполнял небольшие исправления (от 1.0 до 1.1), так как они должны будут выполнять полную регрессию в системе.MSI diff на пакеты для создания патчей

Я хотел бы знать, есть ли инструмент (оплаченный или нет), который займет 2 мс-сборки, выполнив различие/сравнение и выложив полезный установщик патча.

Большую часть времени она будет обновления сборок (модифицированный или новый), но может потребовать некоторого пользовательского сценария (в C#, если это возможно)

источник

2011-01-05 user551962

InstallShield может сделать это при условии:

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

Есть и другие способы сделать это, но для того, чтобы быть честным, требуется довольно много сантехники.

Если честно, я много раз слышал вашу историю «мы должны проверить все», и я никогда не покупал аргумент. Обычно они хотят, чтобы их кусочек, а затем вставлял голову в песок на то, что истинная поверхность испытания. Обычно их реальная проблема - это одна из дисциплины SCM/Build/Release, а не то, является ли установщик крупным обновлением, незначительным обновлением или исправлением. (IMO)

источник

2011-01-05 01:29:14

Я согласен с тестом или нет, но они являются Банком и имеют внутреннюю политику, с которой нам нужно жить. Я посмотрю на InstallShield. – user551962

У InstallShield также есть шаблон QuickPatch.Я никогда не нашел способ автоматизировать его, но если вы освобождаете цикл, это не так часто, он может делать то, что вы хотите. В основном вы кормите его 1 MSI, а затем выбираете кучу файлов, и он будет генерировать MSP только для этих файлов. Поэтому, если вам говорят раз в месяц или около того, что нам нужно исправлять эти 5-10 файлов (вы понимаете), это может сработать для вас. –

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

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

Это утверждение основано на некорректной логике, и тот, кто произнес это, выдувает дым от пресловутого. Существует так же много риска от установки патча, как то, что есть у полного установщика - если тестеры не верят в ваш процесс сборки/выпуска, то оба они должны быть полностью протестированы. Msi - это только упаковка, полная установка или установка патча могут изменить всю систему. Если тестеры хотят найти аргумент «» с патчем, файл abc.dll не изменился, поэтому нам не нужно тестировать функциональность в нем », то вы можете утверждать, что это неправильное мышление - если код с использованием abc.dll изменился, то abc.dll может проявлять другое поведение.

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

В любом случае, я согласен с ответом от @Christopher - такие инструменты, как InstallShield, могут быть использованы для создания единого msi, который является либо полной, если у вас еще нет продукта на вашем компьютере, либо он будет переключитесь в режим обновления, если он обнаруживает элемент с тем же кодом продукта и меньшим номером версии, который уже установлен. Сказав это, невероятно сложно добиться того, что обновление будет работать правильно.

источник

2011-01-05 03:09:51 slugster

Я согласен на 100%, однако мы имеем дело со своей внутренней политикой. они должны видеть, что файлы не были заменены установщиком (наш полный установщик сделает это). – user551962

ROFLMAO. Согласитесь на 100%, но, к сожалению, вы можете или не быть удивлены, сколько раз я слышал, как это произносилось от стольких людей за последние 15 лет. Но я не согласен с тем, что риск между полным и патчем одинаковый. Патч-установка - это * БОЛЬШЕ * риск, потому что ваш полный процесс установки полностью автоматизирован, а процесс определения патча - нет. Это похоже на то, как практикуется один и тот же путь снова и снова, когда приходит время освобождать вас от слышимости и делать это по-другому. –

Кстати, в зависимости от того, как вы определяете «Процесс сборки/выпуска», я могу не согласиться с этой точкой. По моему опыту, процесс сборки/выпуска является 100% -ным доказательством пули. Проблема в том, что проблема SCM связана с тем, как заблокирована базовая линия. Как правило, это не проблема сборки, проблема в том, что они либо не знают, что было проверено, либо они слишком много знают, и теперь они пытаются обойти это, создав программу установки исправлений. –

MSI diff на пакеты для создания патчей

ответ

Смежные вопросы