Сравнение версий

Ключ

  • Эта строка добавлена.
  • Эта строка удалена.
  • Изменено форматирование.

...

  • Насколько старую версию нужно обновлять. Нельзя обновить 2.15 сразу на 2.22, например. Придется обновляться постепенно 2.15 => 2.16 => 2.17…=> 2.22. А это уже прилично времени на скачивания docker образов и операции обновления на сервере с платформой. К тому же после каждого обновления (на каждой промежуточной версии) нужно проверять работоспособность основного функционала, например, дашборды, работа в Дизайнере, темы, кастомные виджеты, авторизация, отправка отчетов и пр.

Примечание

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

  • Есть ли в дистрибутиве с текущей версии платформы на сервере правки в YML или SH файлах. Все эти правки необходимо переносить в файлы дистрибутива новой версии платформы и потом проверять их работоспособность. Кастомные правки не тестируются при выпуске версий. Пример правок: записи extra-hosts, монтирование измененного конфига в контейнер.

  • Кастомные docker образы компонентов платформы. Определить с нуля это уже на работающем сервере не всегда просто, лучше все сразу документировать. Пару признаков, что работают кастомные образы: последняя введенная команда запуска run.sh содержит ключи с кастомными образами, в docker image ls видны образы платформы с необычными тегами (обычный тег это latest и версия платформы). Обновление платформы с кастомной версии обычно не тестируется, и нужно быть готовым к неожиданностям или писать предварительно в техподдержку.

  • Особенности обновления, присущие конкретной версии платформы. Обычно описаны в статьях, например, для 2.22: Особенности обновления на версию 2.22. Соответственно трудоемкость может возрасти, если был серьезно переработан какой-то механизм, который активно используется на проекте.

  • Использование сторонних скриптов, работающих с API компонентов платформы. При изменениях в API скрипты придется корректировать.

  • Использование неофициального API, например, для 2.22 это API рассылки отчетов, создание пользователей. Работа этого функционала не гарантируется после обновления.

  • Кастомизация JS на дашбордах. Здесь могут быть как простые закономерности (обновилась библиотека Highcharts и логика немного поменялась), так и более сложные (использование неофиц API или незадокументированных приемов в коде).

  • Отличный от Ubuntu Server дистрибутив Linux. Тестирование происходит только на рекомендованном дистрибутиве Ubuntu Server, указанном в системных требованиях.

...