Екосистема Qlik перебуває на переломному етапі. AI-системи та автоматизовані пайплайни починають споживати аналітичний вивід як вхідні дані, а не просто показувати його людині на екрані. Команди, які роками нормально справлялися з ручними деплойментами, виявляють, що планка надійності тихо піднялася. Дашборд, на який людина заглядає раз на тиждень – це одне. Модель даних Qlik, яка живить даунстрім-систему щогодини – зовсім інше.
Більшість команд ніколи не картографували, як вони насправді деплоять. Просто роблять те, що завжди робили. Це модель для того, щоб дати цьому назву. П’ять рівнів, від ручного експорту до інфраструктурного рівня. Це не оцінка, щоб засмутитися. Це карта, щоб побачити, де ви зараз і як насправді виглядає наступний крок на практиці.
Це стан за замовчуванням, бо Qlik не надає контроль версій з коробки.
Як це виглядає: хтось експортує QVF з QMC, перейменовує і імпортує на цільовий сервер. Поточна версія застосунку живе на машині того, хто останній її торкнувся. «У кого остання версія Sales app?» – це постійне питання в Slack. Відкат означає надію, що хтось зберіг копію перед зміною. Немає історії того, що змінилось, коли і чому.
Як ви тут опинились: ніхто цього не вирішував. Це те, що трапляється, коли BI-інструмент поставляється без історії деплойменту, а команда достатньо мала, щоб це зійшло з рук.
Коли це ламається: хтось публікує поверх роботи колеги, і ранок зусиль зникає. Продакшн ламається в п’ятницю вдень, і немає чистого способу відкотити. Аудитор запитує, хто змінив певний вираз і коли, і чесна відповідь – ніхто не знає.
Типова команда: один-два розробники, кілька застосунків, низька частота деплойментів. За такого розміру хаос переживний, і саме тому він зберігається.
Команда відчула достатньо болю, щоб додати процес, але процес все ще людський.
Як це виглядає: конвенції іменування на кшталт app-name_20260603_v2. Чеклист деплойменту або ранбук у вікі. Ручні бекапи перед кожною публікацією. Лог змін у спредшиті.
Що покращилось: є хоча б процес, і бекапи десь існують. Нового розробника можна направити до ранбуку, а не до людини.
Що все ще ламається: конвенції іменування зносяться в ту мить, коли двоє людей під тиском дедлайну, і ви отримуєте три файли, кожен з яких стверджує, що він «останній». Чеклист пропускається, коли хтось поспішає. Все ще немає способу порівняти дві версії застосунку. Можна відновити бекап, але неможливо побачити, що було різним між учорашнім робочим застосунком і сьогоднішнім зламаним.
Типова команда: три-п’ять розробників, зростаючий портфель застосунків, і перший справжній координаційний біль. Зазвичай саме тут хтось починає запитувати, чи є кращий спосіб.
Це стрибок, який змінює все, і це також найскладніший стрибок.
Як це виглядає: Qlik-застосунок декомпозується в людино-читабельні файли, зазвичай YAML або JSON. Один файл на міру, вимір, аркуш, змінну і з’єднання. Ці файли живуть у Git: GitHub, GitLab або Bitbucket. Розробники працюють у гілках і зливають через pull request-и. Вперше стає можливим діф. Можна побачити, який саме вираз змінився, в якій мірі, і яким він був раніше.
Ось як виглядає зміна міри після декомпозиції застосунку:
# measures/revenue-per-customer.yaml
qDef: |-
- Sum(Sales)
+ Sum(Sales) / Count(DISTINCT Customer)
qMetaDef:
title: Revenue per CustomerЦей дворядковий діф – це вся суть. До контролю версій ця зміна була невидимою всередині бінарного файлу. Після – це рядок у pull request, який колега може переглянути та поставити під питання перед відправкою.
Що змінилось: «що змінилось?» стає питанням, на яке можна відповісти. Code review стає можливим, бо рецензент бачить діф, а не бінарний блоб. Гілкування означає, що двоє людей можуть працювати з одним застосунком, не перезаписуючи один одного. Історія Git стає аудит-трейлом, який пише себе сам.
Чесна частина: більшість Qlik-розробників ніколи не використовували Git. Крок декомпозиції-композиції потрібно налаштувати і довіряти йому. Навчання – це реальна інвестиція, не один день. Але кожен рівень вище цього побудований на контролі версій, тому віддача накопичується.
Типова команда: п’ять-десять розробників, кілька середовищ, і біль деплойменту, який тепер видимий для менеджменту.
Контроль версій відповідає на «що змінилось?». Пайплайн відповідає на «деплой це однаково кожен раз».
Як це виглядає: CI/CD пайплайн (Jenkins, GitHub Actions, Azure DevOps) спостерігає за Git-репозиторієм. Злиття до основної гілки тригерить автоматичний шлях: деплой у DEV, валідація, промоція в TEST, smoke-тести, очікування схвалення, потім деплой у PROD. Гейти валідації перевіряють синтаксис виразів і конвенції іменування. Smoke-тести підтверджують, що застосунок відкривається і дані завантажуються.
Референсний потік виглядає так:
Developer commits -> CI validates syntax -> Code review
-> Merge to main -> Deploy to TEST -> Smoke test
-> Approval gate -> Deploy to PROD -> VerifyЩо змінилось: деплойменти консистентні і повторювані, бо машина робить їх однаково кожен раз. Ніхто більше не деплоїть з QMC вручну. Відкат – це одна Git-команда: ревертнути коміт і дати пайплайну передеплоїти попередню версію. Сеньйор-розробники перестають бути живим сервісом деплойменту і повертають свій час.
Типова команда: п’ять-п’ятнадцять розробників, часто в регульованій індустрії, або будь-яка команда, яка має системи даунстрім від Qlik, що не можуть толерувати тихі зміни.
На цьому рівні Qlik трактується як будь-яка інша продакшн-система на підприємстві, а не як особливий випадок, який живе за своїми правилами.
Як це виглядає: повний аудит-трейл, де кожна зміна прив’язана до того, хто її зробив, коли і чому, через коміт-повідомлення та історію pull request-ів. Комплаєнс-звітність, яка може згенерувати звіт змін для аудитора без паніки. Один пайплайн, який керує Qlik Sense, Qlik Cloud і QlikView разом. Qlik інтегрований у ширший інженерний процес, а не стоїть поруч з ним.
Що змінилось: Qlik-команда оперує на тому ж рівні зрілості, що й команда інженерії застосунків. «Що змінилось?» можна відповісти для регулятора, а не лише для колеги. Новий розробник онбордиться в задокументований, структурований воркфлоу замість успадкування племінних знань. Вузьке місце одного-сеньйора-розробника зникає, бо процес не залежить від пам’яті однієї людини.
Типова команда: підприємства з десятьма і більше розробниками, регульованими даними, і AI або автоматизованими навантаженнями, що споживають аналітичний вивід. Саме тут планка надійності, про яку я згадував на початку, починає по-справжньому тиснути.
Швидка самооцінка:
Якщо ви на Рівні 0 або 1, найцінніший крок – це не пайплайн. Це дістатися до Рівня 2, контролю версій. Все інше побудовано на ньому, і намагатися автоматизувати процес, який ви не можете діфити – це класти дах раніше стін.
Якщо ви на Рівні 2, складна частина вже зроблена. Додати пайплайн (Рівень 3) прибирає решту ручної роботи деплойменту і є значно меншою поведінковою зміною, ніж вивчення Git.
Якщо ви на Рівні 3 або 4, ви попереду більшості Qlik-команд. Робота тепер – це розширення покриття на більше застосунків і навчання більшої кількості людей, а не новий інструментарій.
Стрибок з Рівня 1 на Рівень 2 – найскладніший, бо вимагає найбільшої поведінкової зміни: вивчити Git, довіряти кроку декомпозиції, переглядати діфи замість файлів. Це також найцінніший стрибок, бо кожен рівень після нього залежить від нього. Якщо ви зробите лише один крок цього року, зробіть цей.
Ніщо з цього не є насамперед технологічною проблемою. Інструментарій для декомпозиції Qlik-застосунків, їх діфу і запуску через пайплайн існує сьогодні, а патерни (Git, pull request-и, CI/CD) доведені по всій решті софтверної індустрії. Складна частина – організаційна: навчання розробників, які ніколи не створювали гілку в репозиторії, і зміна команди від «опублікувати і сподіватися» до «переглянути і злити». Це займає тижні, не дні, і варто бути чесними щодо цього перед початком.
Якщо ваша команда на Рівні 0 або 1 і ви хочете побачити, як виглядає стрибок до Рівня 2 і 3 на ваших власних застосунках, ми підготували 15-хвилинний огляд, який показує кроки декомпозиції, діфу і пайплайну на практиці. Без слайдів. Записатися на огляд.
Коментарів поки немає.
Залишити коментар