Обновление приложения

Процедура обновления приложения заключается в переходе с текущей версии на более новую. Процедура обновления включает несколько этапов.

Особенности и рекомендации по обновлению

Версия 4.16

Изменились рекомендуемые версии СУБД (см. Требования к программному и аппаратному обеспечению):

Microsoft SQL Server рекомендуемая версия 2019;
Oracle рекомендуемая версия 19.

Для Linux для поддержки Java 17 в файле setenv.sh проверьте наличие параметров и при отсутствии добавьте их:

--add-opens java.base/java.net=ALL-UNNAMED \

--add-opens java.base/jdk.internal.loader=ALL-UNNAMED \

--add-opens java.base/java.lang.reflect=ALL-UNNAMED \

--add-opens java.base/java.nio=ALL-UNNAMED

Описание файла setenv.sh, см. Приложение 1. Файл setenv.sh.

Версия 4.15 и выше

В Java 11.0.11 и выше TLSv1/TLSv1.1 шифрование считается устаревшим и отключено по умолчанию.
При обновлении со старых версий Java убедитесь, что сервисы, с которыми настроена интеграция с шифрованием трафика, поддерживают TLSv1.2 или TLSv1.3.

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

перенести каталог <data.dir>/service/ с рабочего стенда на тестовый;
сохранить пароли с рабочего стенда на тестовый.

Это поддержит корректную работу подключений конфигурации импорта, почты и CTI на тестовых стендах.

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

Версия 4.15 и ниже

Особенности и рекомендации по обновлению на версию 4.15 и ниже

После обновления на версию 4.15 (или после запуска приложения на версии впервые) необходимо сделать резервную копию каталога <data.dir>/service/, где <data.dir> каталог с оперативными данными приложения.

Путь к каталогу <data.dir>/service/ задается в основном конфигурационном файле приложения dbaccess.properties в параметре data.dir.

Каталог <data.dir>/service/ будет создан автоматически после первой операции шифрования/дешифрования пароля. Например, после создания подключения к источнику данных при импорте.

Если приложение установлено по рекомендациям, приведенным в настоящем руководстве, то путь к каталогу будет следующий: для Linux: /opt/naumen/nausd4/data, для Windows: c:/naumen/nausd4/data.

Версия 4.14.5

При обновлении приложения с версий, более старых, чем 4.14.5 на версию 4.14.5 и более новые необходимо внести изменения в настройки логирования. Параметры логирования приложения задаются в конфигурационном файле log4j2.properties.

При обновлении приложения с версии меньше, чем 4.7.6 на версию 4.11.5 будет очищена JMS очередь (действия по событиям, построение отчетов, выгрузка списков и т.д.). Чтобы этого не произошло, необходимо сделать промежуточное обновление на любую версию на любую версию между 4.7.6 и 4.11.5.

При обновлении приложения с версии меньше, чем 4.5.8, на более новую, может возникнуть задержка при первом запуске приложения, т.к. в базе данных создаются индексы в таблице TBL_EVENT с целью увеличения производительности операций при работе приложения с данной таблицей.
Продолжительность задержки может составить от несколько минут до нескольких десятков минут. И зависит от множества факторов. Ожидаемое время задержки можно определить при обновлении тестового приложения.

Версия 4.11. Проверка успешной совместной компиляции скриптовых модулей при обновлении на 4.11.0.14 и выше

При обновлении на версию 4.11.0.14 и выше в консоли необходимо выполнить скрипт для проверки успешной совместной компиляции скриптовых модулей.

После выполнения скрипта необходимо вручную исправить ошибки компиляции (например, изменить имена классов, которые совпадают в нескольких модулях). После исправления ошибок, необходимо повторно выполнить скрипт.

* @versions 4.9.0.46, 4.10.0.40, 4.11.0.13

* @author tshajkemelov

* @since Feb 25, 2020

/**
* Скрипт для проверки успешной совместной компиляции скриптовых модулей
*
*/
import org.codehaus.groovy.control.CompilationUnit
import org.codehaus.groovy.control.Phases
import ru.naumen.core.server.script.ScriptModulesService
import ru.naumen.core.server.script.conf.ScriptModule
import ru.naumen.core.server.script.spi.NauCompilerConfiguration
import ru.naumen.core.server.script.spi.ScriptServiceImpl
/**
* Скомпилировать скриптовые модули
*
* @param modules скриптовые модули
*/
static void compileModules(final Collection<ScriptModule> modules) throws ClassNotFoundException
{
final NauCompilerConfiguration configuration = new NauCompilerConfiguration()
final GroovyClassLoader classLoader = new GroovyClassLoader(ScriptServiceImpl.class.getClassLoader(), configuration)
final CompilationUnit compilationUnit = new CompilationUnit(configuration, null, classLoader)
modules.each {final module -> compilationUnit.addSource(module.getCode(), module.getScript())}
compilationUnit.compile(Phases.CLASS_GENERATION)
}
final ScriptModulesService scriptModulesStorageService = beanFactory.getBean(ScriptModulesService.class)
final Collection<ScriptModule> modules = new ArrayList<>(scriptModulesStorageService.getModules())
compileModules(modules)

Процедура обновления

Проверка соответствия текущих компонентов требованиям новой версии
Остановка приложения
Резервное копирование при обновлении
Установка новой версии приложения
Запуск приложения
Проверка работоспособности приложения

Проверка соответствия текущих компонентов требованиям новой версии

Перед обновлением удостоверьтесь, что текущее аппаратное и программное обеспечение соответствует требованиям.

Особое внимание следует уделить версиям Apache Tomcat и OpenJDK. Старые версии программного обеспечения часто несовместимы с новой версией приложения. Рекомендуется обновить их вместе с приложением.

Остановка приложения

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

После оповещения пользователей остановите приложение.

Резервное копирование при обновлении

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

Выполните резервное копирование исполняемых файлов приложения и базы данных, с которой работает приложение.

Установка новой версии приложения

Убедитесь, что версии Apache Tomcat и OpenJDK, используемые приложением, соответствуют требованиям.

На Linux все операции с файлами приложения необходимо выполнять от имени того пользователя, с правами которого приложение запускается (по умолчанию nausd4).

Установка новой версии приложения:

Создайте в директории <app_dir>/deploy/ каталог <dd_mm_yyyy>, соответствующий текущей дате.

для ОС Linux: /opt/nausd4/deploy/2015-04-24
Сохраните в созданный каталог предоставленный вам файл новой версии приложения, вида sdng-war-4.X.X.X.war.
Удалите каталог <app_dir>/tomcat/webapps/sd/ и текущую версию приложения <app_dir>/tomcat/webapps/sd.war.
Скопируйте на место удаленных файлов новую версию приложения и переименуйте файл в sd.war.
Удалите содержимое каталога <app_dir>/tomcat/temp.

В директории <app_dir>/tomcat/webapps должен быть только один каталог с файлами приложения. Если будет два каталога с файлами приложения, то Tomcat попытается запустить приложение два раза, что приведет к частичной или полной неработоспособности приложения.

Недопустимо просто переименовать каталог или файл sd.war со старой версией приложения и оставить его в той же директории.

Каталог со старой версией необходимо удалить.

Если после запуска приложение автоматически не разворачивается и на экране отображается "Ошибка 404", то необходимо вручную распаковать установленный sd.war (как ZIP-архив) в каталог <app_dir>/tomcat/webapps/sd/.

Запуск приложения

Выполните запуск приложения, согласно рекомендациям.

В процессе запуска рекомендуется контролировать сообщения, выводимые в журналах работы приложения.

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

Проверка работоспособности приложения

После завершения процесса обновления и запуска приложения выполните проверку работоспособности приложения.

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

О проблемах, возникших после обновления приложения, необходимо сообщать на cs@itsm365.com.

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