Администраторы компьютеров организации часто очень внимательно относятся к тому, что они разрешают устанавливать на компьютеры. Они часто отключают автоматические обновления и вместо этого проверяют обновления вручную и отправляют их на компьютеры, если уверены, что это не нарушило рабочие процессы пользователей.
Но затем приходит Chrome, который имеет тенденцию обновляться автоматически и часто. Я не знаю, предоставляет ли Chrome «закрытое» обновление, которое позволяет администраторам организации тестировать обновления, прежде чем пускать их внутрь организации. Но я могу представить, что это так.
У меня такой вопрос. Как приложения, которые обновляются автоматически, часто и часто без ведома пользователя, видны администраторам компьютеров организации? Если бы мне пришлось создать такое приложение, потребовалось бы этим администраторам отключить автоматические обновления? Или им было бы хорошо, если бы они могли заранее проверить обновления?
Я понимаю, что этот вопрос может быть слишком широким и сильно зависеть от конкретной организации. Меня больше интересуют ответы «лучшие практики» и «общие правила».
Задний план
Причина, по которой я спрашиваю, заключается в том, что идея непрерывного развертывания становится все более сильной в разработке программного обеспечения. Это намного проще с серверными компонентами, когда вы управляете сервером, на котором развернуто программное обеспечение. Но при установке программного обеспечения непосредственно на клиентские станции становится сложно. Я считаю, что Chrome выполняет непрерывное развертывание, поэтому он полагается на полностью автоматизированные обновления новых выпусков. В крайних случаях это могут быть ежедневные инкрементные сборки. Что я хочу знать, каких проблем мне следует ожидать от администраторов, если я буду продавать приложение, которое пытается обновляться еженедельно или даже ежедневно? И, возможно, что такая автоматическая система обновлений должна предоставить администраторам, чтобы им было проще. Поскольку я бы не хотел, чтобы администраторы выступали против приложения, если оно нарушает их рабочие процессы обновления.
В случае с Google Chrome это было решено тремя способами:
В версиях Windows есть вариант установки MSI для предприятий, специально для решения этой проблемы. Обновления доступны через канал для администраторов, поэтому они могут проверять и развертывать обновления по мере необходимости.
Установки Chrome по умолчанию привязаны к пользователю и не могут (и не влияют) влиять на других пользователей или элементы системного уровня, поэтому даже если автоматическое обновление включено, в худшем случае это означает очистку профиля пользователя, что в контролируемой среде часто сводится к удаление некритических вещей, таких как реестр пользователя и некоторые AppData. Большинство предприятий хранят документы и т. Д. Вне профиля пользователя, и важные данные приложений реплицируются и синхронизируются с серверами (например, CalDAV, IMAP, Exchange для PIM и Git для исходного кода и т. Д.), Поэтому влияние довольно невелико.
Для других операционных систем (macOS, Linux) установка также имеет оба варианта (установка локального пользователя или установка системы), но для управления установкой системы как Linux, так и системы на базе macOS имеют хороший набор инструментов, чтобы эта работа работала так, как они есть установщики на основе пакетов, требующие установки / обновления / удаления одного файла .pkg / .deb / .rpm, либо копирования одного каталога (т. е. формата .app). Опять же, настройки и профили хранятся внутри дома пользователя в каталоге, отдельном от фактических файлов пользователя, поэтому даже в худшем случае сценарий идентичен любому другому типу проблемы с профилем: стереть профиль, и пользователь может вернуться к работе.
Я уверен, что есть приложения, которые не предлагают управляемые установки и работают только с автоматическими обновлениями, но я не встречал комбинации средств обновления на уровне системы и автоматического обновления ни в одной корпоративной среде, где это был единственный выбор. Если у вас есть приложение, которое вы хотите продать, по крайней мере предложите упакованную / контейнерную версию, которую можно добавить или удалить как единый элемент с доступом на уровне пользователя. Это означает, что им может управлять как пользователь, так и администраторы.
Лучше всего было бы иметь несколько упакованных сборок, чтобы вы могли обслуживать всех. Настройку внутреннего CI / CD для этого часто нужно исправить один раз, а затем только поддерживать для изменений. Когда программное обеспечение построено / скомпилировано и т. Д., Последний этап упаковки может включать в себя сборки автоматизированного установщика, упакованные сборки, сборки MSI, сборки PKG и т. Д., И вы сможете обслуживать все с минимальными затратами для себя.
Ответ будет зависеть от того, какие методы использует платформа для обновления программного обеспечения. Мой ответ будет нацелен на платформы, которые я знаю лучше всего, а именно Ubuntu и Fedora. Они используют пакеты deb и rpm соответственно для установки программного обеспечения и обновлений, различия между deb и rpm незначительны в контексте этого вопроса.
Установленные файлы по большей части будут принадлежать пользователю root, и установщик должен будет запускаться от имени root, чтобы иметь права на обновление файлов. Само приложение будет запускаться от имени непривилегированного пользователя без возможности обновления файлов. Если приложение попытается обновить себя, оно не сможет этого сделать.
Приложение может информировать пользователя о наличии обновления. Но если он действительно хочет установить обновление, лучшее, что он может сделать, это запустить диспетчер обновлений, который откроет окно, предлагающее пользователю ввести необходимый пароль.
На этом этапе автоматическое обновление будет сокращено до ярлыка для открытия диспетчера обновлений. Таким образом, вопрос будет заключаться в том, хотите ли вы, чтобы каждый пользователь в вашей организации имел права администратора на своем компьютере.
Стратегии развертывания обновления
В большой организации вы, вероятно, захотите сначала внедрить изменение только для небольшого числа пользователей и постепенно увеличивать скорость, пока вы не слышите отчеты о проблемах от пользователей.
Вам нужно будет взвесить это с учетом того, насколько критично обновление. Если он исправляет уязвимость, которая активно используется, или если ошибка может привести к потере данных или невозможности загрузки устройств, вы можете захотеть, чтобы обновление развертывалось быстрее.
Следует принять во внимание риск того, что с момента выпуска обновления может пройти время, пока системный администратор не поймет, что существует критическое обновление, требующее ускоренного развертывания.
В крупной организации, скорее всего, будет достаточно системных администраторов, чтобы иметь возможность быстро оценить каждое обновление программного обеспечения и решить, как быстро развернуть его на всех машинах. У небольшой организации не будет этих ресурсов, и ей, возможно, придется достаточно доверять поставщику программного обеспечения, чтобы начать развертывание обновлений программного обеспечения без этапа проверки вручную.