Со стороны поставщика программного обеспечения (мне никогда не приходится развертывать собственный продукт дальше, чем несколько тестовых машин), мне не хватает знаний о «стандартных» или «доступных» инструментах, которые администраторы могут использовать для изменения бренда программного обеспечения. и как это влияет на развертывание.
Под «брендом» я имею в виду изменение пользовательского интерфейса таким образом, чтобы он отображался с конкретной информацией компании, такой как изображения, о и т.д.
Вы бы хотели заклеймить сам процесс установки или только конечный продукт?
Если только конечный продукт, допустимо ли запускать отдельный этап распространения, чтобы применить брендинг, или его следует включить в установку?
Есть ли у вас существующий процесс и инструменты для ребрендинга? - например, установка msi на чистую машину, применение брендинга, фиксация изменений и повторное объединение пользовательского msi
Как бы вы управляли изменениями между версиями продукта?
С какими форматами легче работать?
Учитывая разные сценарии развертывания, будет ли разница между
С какими еще проблемами сталкиваются поставщики программного обеспечения в корпоративной среде при развертывании программного обеспечения под вашим брендом? Какие вопросы я не знал задать?
Сначала небольшая мыльница. Лично я не вижу преимуществ в «брендинге». Если моя компания не писала программное обеспечение, я не считаю это «знаком чести» наклеивать мое имя на это программное обеспечение, поскольку, когда с ним возникают проблемы, я не смогу их решить. Вы обращаетесь к системным администраторам, но, возможно, вы больше думаете об аудитории «Поставщики управляемых услуг» (которые, кажется, просто съедают такие вещи. Я думаю о различных сторонних компаниях по резервному копированию, например, которые позволяют своим "партнерам" наклеивать логотип поверх фактического названия провайдера ...)
Если я заменю слова «индивидуальная конфигурация» вместо «брендинг», я обнаружу, что ваш запрос очень уместен для того типа работы, которую я выполняю по подготовке стороннего программного обеспечения для развертывания на ПК и серверах на сайтах моих клиентов. (Мне лично было бы приятно, если бы третьи стороны просто начали использовать установщик Windows и прекратили его работу с пользовательскими развертываниями SETUP.EXE ... GRR!)
Все это в сторону, чтобы ответить на ваши конкретные вопросы:
Вы бы хотели заклеймить сам процесс установки или только конечный продукт?
и
Если только конечный продукт, допустимо ли запускать отдельный этап распространения, чтобы применить брендинг, или его следует включить в установку?
Я бы предпочел, чтобы брендинг был добавлен после «стандартной» установки «конечного продукта». Это дает мне возможность всегда устанавливать «стандартный» дистрибутив и пересматривать «фирменные» ресурсы отдельно от самого программного обеспечения. Что-то примененное постфактум было бы хорошо.
Например, с настройками на основе MSI я вижу применение файла преобразования (MST) как модификацию «стандартного» развертывания, но у меня всегда есть возможность «вернуться» к стандартному развертыванию, если я хочу быть уверенным. что мой "брендинг" не вызывает проблем.
Как бы вы управляли изменениями между версиями продукта?
В идеале вы должны поддерживать обратную совместимость с предыдущими ресурсами брендинга, чтобы тот же процесс «брендинга» работал и в будущих версиях (изящный отказ, когда в старых версиях ресурсов брендинга не указаны значения для будущих механизмов брендинга). Я бы поддерживал ресурсы брендинга в системе контроля версий, как я делаю с файлами конфигурации, преобразованиями MSI и т. Д.
С какими форматами легче работать?
Исполняемые двоичные файлы создают потенциальные проблемы в среде Windows «AppLocker», где их может потребовать подписать. Я бы предпочел, чтобы брендинг хранился в неисполняемом файле. JAR-файл (в основном ZIP-файл) подойдет, как и «куча файлов».
Учитывая разные сценарии развертывания, будет ли разница между
Серверный продукт, возможно, несколько серверов и пользовательский настольный продукт - они будут установлены с помощью политики установки программного обеспечения групповой политики или сценариев запуска, поэтому нет никакой разницы. В идеале, этап брендинга может быть таким же простым, как установка дополнительного MSI-файла, который помещает «волшебный файл» (или волшебный «набор файлов») в нужное место, а брендинг «просто происходит».
Серверный продукт, который также действует как точка распространения для настольного продукта (например, JNLP, msi, плагин) - я не использую подобные продукты, потому что я не разрешаю пользователям устанавливать программное обеспечение. Если бы я собирался сделать что-то подобное, я бы предположил, что установщик продукта получил бы доступ к определенному DNS-имени в локальной зоне DNS через HTTP (HTTPS и т. Д.), Чтобы загрузить брендинг из определенного имени файла (подумайте "http://productname-branding.yourdomain.com/branding.zip"). Тогда распространение фирменного стиля будет заключаться в размещении файла (ов) фирменного стиля на веб-сервере.
С какими еще проблемами сталкиваются поставщики программного обеспечения в корпоративной среде при развертывании программного обеспечения под вашим брендом?
У меня никогда не было возможности «брендировать» какое-либо программное обеспечение, поэтому я не могу сказать.
Когда мы думаем о «индивидуальной конфигурации», а не о «брендинге», наличие исчерпывающей документации о настраиваемых функциях, как говорит Крис С., - это хорошо. Очень редко я сталкивался с продуктами, которые достаточно хорошо описывают различные механизмы конфигурации и способы управления ими (кроме пользовательского интерфейса). Лично я считаю, что любой интерфейс конфигурации пользовательского интерфейса должен иметь «поддерживаемый» метод программных манипуляций, также не требующий какого-либо взаимодействия с пользователем. Мне не обязательно знать о ваших различных непрозрачных репозиториях данных двоичной конфигурации, но мне нужны хорошие интерфейсы, которые позволили бы мне управлять конфигурацией из сценария / установщика и т. Д.
Я думаю, вы больше нацеливаетесь на этот вопрос на системного администратора, который воображает себя «поставщиком управляемых услуг» (MSP). В такой ситуации все, что я говорю выше, вероятно, неверно. MSP, вероятно, захотел бы, чтобы брендинг был интегрирован непосредственно в установщик, чтобы они могли раздавать EXE, MSI и т. Д. Своим клиентам, и брендинг происходил бы «волшебным образом» во время установки.
С точки зрения клиента для MSP, использующего подобное программное обеспечение, все, что я прошу, - это предоставить мне автоматизированный способ установки и удаления вашего продукта детерминированным и надежным способом, и я был бы счастлив.