У кожної Qlik-команди є своя історія жахів з розгортанням.
Можливо, це був баг у load-скрипті, через який додаток потрапив у продакшн зі зламаним завантаженням даних, і вранці понеділка 400 користувачів відкрили свої дашборди й побачили порожні графіки. Можливо, це був конфлікт редагування — коли один із двох розробників, що працювали над додатком у вихідні, втратив усю свою роботу. А можливо, це був керівник, який запитав «що змінилось?» після того, як дані перестали збігатися з фінансовою системою.
Це не крайні випадки. Це вівторок.
І ці проблеми продовжують виникати через архітектуру QlikView та наслідки, з якими більшість відділів Business Intelligence мають справу щодня.
Як і майже все інше в сучасних технологічних стеках, практично кожен артефакт — це текстові файли, збережені в Git-репозиторії. Код додатків, конфігурації інфраструктури, міграції баз даних, конфігураційні файли — фактично кожен артефакт, на який мають дивитися людські очі, можна порівняти, переглянути та відстежити.
Qlik-додатки — це бінарні файли.
QVF-файл — це бінарний формат, який не можна відкрити чи редагувати текстовим редактором. Ви не можете побачити різницю між версіями. Ви не можете зробити merge змін двох розробників. Ви не можете робити code review.
Саме це єдине архітектурне рішення призводить майже до всіх проблем, з якими стикається Qlik у контексті розгортання продуктів.
Контроль версій — це фундаментальна частина робочого процесу більшості розробників. Усі зміни версіонуються. Кожна зміна коду документується з інформацією про те, хто зробив зміну, коли вона була зроблена, diff коду та часто опис зміни.
У Qlik нічого з цього немає.
Коли ви зберігаєте Qlik-додаток, вся інформація з попередніх сесій втрачається. Немає можливості «скасувати» зміни до попереднього стану додатку. Немає запису зроблених змін. Немає способу порівняти цьоготижневу версію додатку з минулотижневою.
Наслідок: коли щось ламається, розслідування починається із запитання «хтось пам’ятає, що змінювали?» — а не з git log.
Типова ситуація: два розробники, що працюють над одним Qlik-додатком, можуть розробляти його лише послідовно — тобто лише один з них може редагувати додаток у будь-який момент часу. Ще поширеніше — коли двом розробникам потрібно створити дві різні версії одного додатку, а потім вручну об’єднати оновлення в спільну базу. Це ручне злиття — непроста задача, особливо для великих і складних додатків.
Немає гілок. Немає злиття. Немає розв’язання конфліктів.
На практиці команди розробляють обхідні шляхи:
Жоден з цих підходів не масштабується за межі 2–3 розробників.
Стандартний процес розгортання Qlik:
Це метод «скопіюй і молися». І він працює — деякий час.
Типові помилки:
Немає пайплайна. Немає автоматизації. Немає кроку валідації між «розробник каже, що готово» і «400 людей дивляться на це».
Ми практикуємо code review. Інший член команди не зливає зміну в продакшн, доки не погодиться, що код готовий. Code review виявляє баги, забезпечує дотримання практик кодування та поширює знання про конкретні частини кодової бази серед усіх членів команди.
У Qlik немає еквіваленту.
Розробник вносить зміни до складного виразу Set Analysis, формули змінної чи навіть load-скрипту. І вони розгортаються одразу. Без review, без необхідності ручного підтвердження зміни, без будь-якого розгляду того, чи була вона перевірена та валідована кимось іншим.
Це не тому, що команди не хочуть code review. Це тому, що інструменти погані. Ви не можете переглянути бінарний файл і не можете прокоментувати конкретний рядок QVF.
Коли продакшн-дашборд ламається або показує неправильні цифри, всі хочуть знати: «Що змінилось?»
Для користувачів контролю версій відповідь займає 30 секунд. git log, знайти, які коміти змінили рядок, git show хеш коміту — і готово.
У Qlik відповідь може зайняти години — або так і не з’явитися. Тому що немає запису про те, що змінилось, коли і ким.
Це більше, ніж просто незручність. У високорегульованих галузях, таких як фінансові послуги, охорона здоров’я та державний сектор — нездатність створити журнал змін означає невідповідність вимогам. Аудитори хочуть знати, що ви керуєте змінами у своїх додатках, і відповідь «ми не ведемо історію змін для наших звітних додатків» їх не влаштує.
Якщо все інше не допомагає під час розгортання, ваш план має бути — відкотитися до попередньої робочої версії.
У Qlik це означає:
Більшість команд не можуть чесно відповісти «так» на всі чотири запитання. Тому коли зміна щось ламає, фактичною відповіддю стає «виправляй на ходу під тиском» — що саме по собі створює нові проблеми.
Усі ці проблеми не новина для жодного з нас, хто працює в Qlik-командах і стикається з ними щодня. Тож чому вони досі існують?
Фундаментальне рішення: ставтеся до Qlik-додатків як до коду.
Це означає:
Це не сценарій майбутнього — це реальність уже сьогодні. Існують продукти, які можуть взяти Qlik-файл (у бінарному форматі) і дозволити працювати з ним як зі звичайним файлом коду (у текстовому форматі), щоб ви могли використовувати всю потужність Git. Контроль версій — перевірена та прийнята практика в традиційній розробці програмного забезпечення вже десятиліттями, і тепер вона вперше доступна для Qlik-розробників та аналітиків даних.
Якщо ваші команди зможуть перейти на такий режим роботи, жахливі історії з розгортаннями залишаться в минулому. Не тому, що ваша команда перестане робити помилки (скоріш за все ні), а тому, що люди зможуть помічати, відстежувати та виправляти помилки способами, які відчуваються безпечними.
DatalabsUa створює DevOps-інструменти для Qlik-аналітики. Дізнайтеся, як QOps забезпечує контроль версій на базі Git для Qlik.
Коментарів поки немає.
Залишити коментар