Ви з тих людей, хто розгортає Qlik-додатки шляхом простого експорту QVF, перейменування файлу та імпорту в цільове середовище? Якщо так — ви не одні! Фактично, у кожній Qlik-команді, з якою ми працювали, це поширена практика. І майже в кожному випадку їм доводилось мати справу з наслідками, коли щось йшло не так і потрібно було терміново розгорнути додаток, щоб виправити проблему. Тож усім, кому «не доводилось вручну видаляти зламане розгортання після спроби встановити QVF-файл під час критичного дедлайну» — вітаємо. Ви в меншості.

Те, що нам доводиться вручну розгортати оновлення на продакшн, не обов’язково означає, що все зламано. Ні, ручні розгортання працюють. Вони працюють, доки не перестають працювати. Вони перестають працювати, коли розгорнуто неправильну версію. Вони перестають працювати, коли п’ятничне розгортання ламає критичний дашборд, на який покладаються 200 користувачів у понеділок. Вони перестають працювати, коли потрібно відкотитися до попередньої версії — а відкочуватися нікуди.

Цей посібник описує процеси, необхідні для стабільного розгортання Qlik-середовищ при нестабільному середовищі розробки. Він стане в нагоді незалежно від того, чи ви єдиний розробник із п’ятьма додатками, чи команда з десяти людей, що керує понад 100 додатками.

1. Розділіть середовища — і дотримуйтесь цього

Кожне розгортання Qlik має проходити через щонайменше три середовища:

• Розробка (DEV) — де розробники вільно створюють та експериментують
• Тестування / QA (TEST) — етап, на якому зміни валідуються перед розгортанням.
• Продакшн (PROD) — де кінцеві користувачі працюють з дашбордами та звітами

Одне з найпоширеніших непорозумінь у світі DevOps — це ставлення до DEV і PROD як до одного сервера. Публікація в потік, який бачать кінцеві користувачі — це не процес розгортання, це просто публікація.

Найкраща практика: Ми рекомендуємо використовувати окремі сайти в Qlik Sense (або окремі тенанти в Qlik Cloud) для кожного середовища. Якщо бюджетні обмеження не дозволяють мати окремі сервери, рекомендуємо щонайменше окремі потоки та суворі права публікації.

Золоте правило: Жоден розробник не повинен мати права публікації в Production-потік. Крапка.

2. Ніколи не розгортайте з Desktop розробника

Один з найпоширеніших антипатернів розгортання Qlik:

1. Розробник відкриває Qlik Sense Desktop
2. Створює або модифікує додаток
3. Експортує QVF з Desktop
4. Імпортує QVF у серверне середовище
5. Публікує в потік

Кожен крок у цьому ланцюжку — це ризик:

• Версія Desktop може відрізнятися від серверної версії
• Підключення до даних на Desktop не відповідають серверним підключенням
• Section Access може посилатися на локальні групи замість серверних
• Ніхто не знає, який експорт з Desktop є «справжньою» поточною версією

Найкраща практика: Завжди розробляйте у DEV-середовищі на сервері, а не на Desktop. Якщо це неможливо в конкретних ситуаціях, Desktop може використовуватися лише до моменту, коли додаток буде повторно розгорнуто на DEV-сервер для подальшого тестування перед просуванням у TEST-середовище.

3. Створіть чеклист розгортання

Перед тим як будь-який додаток переміщується з одного середовища в інше, перевірте:

• Підключення до даних вказують на правильне середовище. DEV-бази vs PROD-бази
• Правила Section Access є коректними для цільового середовища
• Усі змінні посилаються на правильні шляхи та сервери
• Load script не містить жорстко закодованих шляхів з іншого середовища
• Додаток успішно розгорнуто у вихідному середовищі
• Надано результати тестування запропонованих змін
• Не-розробник переглянув зміни (якщо застосовно)

Письмовий чеклист допомагає виявити помилки та друкарські помилки, які часто просковзують через тріщини пам’яті. Його легко зробити ефективнішим: роздрукуйте його, прикріпіть над клавіатурою, щоб він завжди був перед очима, і використовуйте кожного разу.

4. Версіонуйте додатки — навіть вручну

Мінімально можливий контроль версій для Qlik-додатків:

1. Перед кожним розгортанням експортуйте поточний QVF з продакшну
2. Назвіть його з датою та версією: Sales-Dashboard_v2.3_2026-03-15.qvf
3. Збережіть файл у спільну теку команди, доступну для всіх
4. Зберігайте щонайменше останні 5 версій

Це не ідеально. Але це незрівнянно краще, ніж не мати жодної можливості відкотитися.

QVF-файли мають бінарний формат, тож ви не можете порівняти їх. Ви не можете переглянути changelog між версіями, скажімо, v2.2 та v2.3, і дізнатися, що змінилось. Якщо потрібно відкотитися до старішої версії, залишається лише сподіватися, що зміни між версіями не надто радикальні.

Усі ці методи мають недоліки. Найкращий підхід — розкласти додаток на читабельні JSON/YAML-джерела та зафіксувати їх у Git. Це дає справжній контроль версій вашого додатку. Усі зміни формул і змінних відображатимуться як однорядкові зміни в Git Diff, і ви зможете повноцінно створювати гілки та зливати код (як і з будь-яким іншим проєктним кодом у вашій компанії). Саме тут допоможе QOps — він трансформує бінарний формат Qlik у зручний для Git, читабельний формат.

5. Стандартизуйте процес просування

Чітко визначте, як додатки переміщуються з одного середовища в інше, і зробіть цей процес достатньо простим для автоматизованих інструментів, але водночас зрозумілим для будь-якого члена команди, щоб він міг виконати розгортання вручну в екстреній ситуації, без залежності від «племінних знань».

Надійний процес просування виглядає так:

DEV → (export) → TEST → (validate) → PROD
↓                    ↓
Change log          Sign-off
оновлено            необхідний

Для кожного просування:

• Розробник ініціює запит (а не затверджує сам)
• Зміна задокументована: що змінилось, чому та що потрібно протестувати
• Хтось валідує зміни в TEST перед публікацією в продакшн
• Розгортання в PROD має виконувати призначений для цього член команди, а не сам розробник

Кому допомагає розділення обов’язків? Усім, чий сайт зазнає непередбачуваних змін після чергового «розгортання дня». Сенс додатку губиться, коли одна й та сама людина є і автором, і спеціалістом з розгортання. При кожному розгортанні завжди виникають друкарські помилки, пропущені змінні чи неправильні теги. Навіть наявність другої пари очей, що помічає ці дрібні помилки, значно підвищує надійність.

6. Керуйте підключеннями до даних для кожного середовища

Одна з найскладніших частин розгортання Qlik: підключення до даних.

Ваш додаток вказує на базу даних розробки в DEV та на продакшн-базу в PROD. Коли ви експортуєте QVF з DEV та імпортуєте в PROD, посилання додатку включатимуть підключення до неправильної бази даних.

Варіанти вирішення:

1. Конвенція іменування підключень — називаємо підключення однаково в кожному середовищі, але налаштовуємо кожен сервер на різні бази даних. В додатку ми посилаємося на Sales_DB у кожному середовищі. Однак на DEV воно вказує на dev-sql01, а на PROD — на prod-sql01.
2. Підключення на основі змінних — зберігаємо рядок підключення у змінній Qlik і встановлюємо її для кожного середовища у файлі властивостей або include-скрипті.
3. Автоматична заміна — використовуємо інструменти розгортання для автоматичної підміни посилань на підключення для продакшн-середовища під час розгортання.

Мабуть, це очевидно, але ручне редагування підключень після кожного імпорту — це ненадійно і не масштабується.

7. Не пропускайте тестування

«Працює на DEV» — це не підтвердження готовності до розгортання.

Перед просуванням у продакшн перевірте в TEST-середовищі:

• Завантаження даних завершується успішно — ті ж обсяги даних, ті ж розклади
• Усі візуалізації відображаються коректно — перевірте вирази, відсутні виміри
• Section Access працює — увійдіть під різними ролями для перевірки доступу
• Продуктивність прийнятна — TEST має мати аналогічні обсяги даних до PROD. Це означає, що дані мають бути синхронізовані між середовищами як актуальні, так і історичні, для забезпечення точності та ефективного тестування.
• Немає регресій — функціональність, що працювала раніше, продовжує працювати після змін

Якщо ви не можете протестувати — ви не можете розгортати. Нетестоване розгортання в продакшн може коштувати досить дорого, щоб купити весь час у світі.

8. Ведіть журнал змін

Для кожного розгортання в продакшн фіксуйте:

• Дату та час розгортання
• Хто розгорнув зміну
• Що змінилось — конкретні додатки, конкретні модифікації
• Чому — бізнес-причина або номер тікета
• Як відкотитися, якщо щось піде не так

Цей журнал змін стає безцінним, коли:

• Керівник запитує «що змінилось минулого тижня?»
• Щось ламається і потрібно визначити, яке саме розгортання спричинило проблему
• Аудитор просить доказ наявності контролю змін

Не має значення, як ви документуєте цю інформацію — спільна таблиця, wiki-сторінка чи навіть Git commit history цілком підійдуть.

9. Автоматизуйте що можете

Ручні розгортання не масштабуються. Це справедливо для невеликих організацій із 5 додатками та кількома адміністраторами, які готові дотримуватися невеликого чеклиста. Але з 50+ додатками у розгортуваному програмному середовищі та аналогічною кількістю людей, які намагаються розгортати щодня — помилки неминучі, а ручні процедури зрештою розвалюються.

Що можна автоматизувати у розгортаннях Qlik:

• Експорт та імпорт додатків — через Qlik Sense Repository API або PowerShell
• Конфігурація підключень до даних — конфігураційні файли для кожного середовища
• Планування перезавантажень — створення завдань через API після розгортання
• Сповіщення — повідомлення в Slack/Teams при успішному або невдалому розгортанні
• Відкат — автоматичний відкат до попередньої версії, якщо нова не завантажується

Повний CI/CD для Qlik Sense (чи будь-якого продукту Qlik) — тема, яка активно обговорюється, і з допомогою Repository API та можливостей QOps ми можемо підтвердити: повний CI/CD цілком реальний. Ось базова структура повного пайплайна:

1. Розробник фіксує зміни в Git
2. Пайплайн запускається: експортує додаток, виконує перевірки валідації
3. Додаток автоматично розгортається в TEST
4. Після ручного підтвердження пайплайн просуває в PROD
5. Пост-розгортальне перезавантаження перевіряє працездатність додатку

Це не теорія — команди вже працюють за таким підходом сьогодні.

10. Плануйте відкат до початку розгортання

Це дуже просто. Кожного разу, коли ви розгортаєте щось у продакшн, ви маєте бути готові відповісти на запитання «Що буде, якщо це зламає продакшн?» Кожне розгортання має містити відповідь на це запитання як частину самого процесу розгортання.

Мінімальний план відкату:

• Зберігайте попередній QVF-експорт у доступному місці
• Документуйте, яка версія працювала до розгортання
• Знайте, як повторно імпортувати та опублікувати попередню версію
• Знайте стан підключень до даних попередньої версії

Кращий план відкату:

• Автоматичний відкат одним кліком (повторне розгортання попередньої версії з Git)
• Історія розгортань, що показує, що саме працювало у будь-який момент часу
• Миттєвий diff між зламаною версією та останньою робочою

DatalabsUa створює DevOps-інструменти для Qlik-аналітики. QOps забезпечує контроль версій на базі Git та автоматизацію CI/CD для Qlik Sense, Qlik Cloud та QlikView.