Последовательность обновления Simple Application

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

:red_question_mark: Что такое Simple Application?

:left_speech_bubble: Simple Application (SA) — базовое приложение платформы SimpleOne, содержащее ключевой набор функций и сущностей, необходимых для работы платформы и дополнительных приложений (ITSM, ITAM и др.).
:warning: На версиях платформы SimpleOne 1.32.0 и ниже, версия SA обязана соответствовать версии платформы на инстансе.


:red_question_mark: Как правильно обновлять Simple Application?

:warning: Устанавливайте пакеты обновления SA только после полного завершения обновления платформы деплоем плейбука. Опережающая установка может привести к неполадкам.
:warning: SA обновляется строго последовательно! Пропускать промежуточные версии запрещено! Например, для обновления с 1.29.0 до 1.32.0 необходимо после завершения деплоя плейбуком последовательно установить пакеты обновления: 1.30.0 → 1.31.0 → 1.32.0.


:red_question_mark:Наш экземпляр размещен в облаке SimpleOne. Как понять, что обновление платформы завершено и можно приступать к обновлению SA?

:left_speech_bubble: При обновлении Cloud-инсталляций, SimpleOne оповещает о завершении обновления платформы в заявке. Если нужно узнать статус работ срочно — обращайтесь на круглосуточную линию поддержки: +7 (495) 181 85 20


Пакеты для обновления и инструкции по импорту:

📥Пакеты для обновления Simple Application и инструкция по импорту

Последовательность действий по импорту (установке) пакета указана в официальной документации в разделе Импортируемые пакеты.
Если при импорте пакетов в списке изменений содержатся записи в статусах Skipped / Collision (Пропущено/ Коллизия) необходимо решить коллизии и завершить импорт пакетов. Решение коллизий также описано в документации - Правила решения коллизий.

Для удобства, в текущей статье сохраняем пакеты для обновления с устаревших версий:

9 лайков

Ришат, в пакете Simple Application build.1232.sop есть изменение, которое переопределяет обязательность для атрибута Владелец для таблицы Услуга (политика =protected).

В результате появляется ещё одно обязательно поле на форме услуги, а т.к. переопределить его нельзя, появляется проблема в бизнес процессе заказчика (оно не должно быть обязательным).
Что интересно, на другом стенде (обновлённого по запросу вашими коллегами) версии 1.20, этого изменения нет.

Почему? Можно ли это изменение как-то откатить со стенда после установки sop? Очень мешает…

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

Есть ли SOP-пакеты для обновления на 1.26.0?

Добавил в основную часть.

есть ли особенности установки SOP при обновлении на несколько версий релизов в 1 шаг?

например, нам необходимо обновиться с версии 1.25 до 1.30.

от ТП рекомендовано установка релиза за 1 шаг (REQ0025084).

т.е. сразу поставить 1.30 и после накатить дельту SOP всей линейки релизов из вашего списка , т.е. [SA] 1.26.0.sop, [SA] 1.27.0.sop, [SA] 1.28.0.sop, [SA] 1.28.2.sop, [SA] 1.29.0.sop, [SA] 1.30.0.sop

возможно кто о уже повышался как мы … может подскажете нюансы, если они были…

поделитесь, пожалуйста.

также - раз уж можно релизы за 1 шаг, то может и SOP есть типа “все в одном с 1.25 на 1.30”?

Да, можно обновить платформу с версии 1.25 до 1.30, а затем установить пакеты обновления (дельта-пакеты) SA. Однако общего дельта-пакета SA для перехода с версии 1.25 на 1.30 не существует.

Добрый день!

Нюансы всегда есть :grinning_face:
У нас на данный момент установлена 1.28.0. А первая установленная версия была когда-то 1.13.1. С тех пор было уже несколько обновлений (прыгали через несколько версий, каждую отдельно не ставили), и каждое обновление приносило свои “сюрпризы”. Большинство “сюрпризов” можно было увидеть (предсказать) на этапе установки sop-пакета - при разборе коллизий. Но были и совсем неожиданные “сюрпризы”… И большинство их них прилетело при обновлении до версии 1.28.0 - там у нас большой “прыжок” через несколько версий был. Например, в версии 1.24.2 в таблице org_department поле department_head превратилось в поле head_id, и пришлось менять все скрипты (виджеты), которые использовали это поле. Вас конкретно именно это не заденет, раз обновляетесь с версии 1.25.0. Но судя по такому подходу производителя к собственным решениям заказчика, в любой момент может выплыть что-то подобное. Я уж не говорю про изменённые страницы на портале, изменённые формы в разных базовых таблицах…

В общем, по-хорошему, надо делать полную проверку всего функционала после каждого обновления.

1 лайк