У вересні 2022 року ми випустили свій власний продукт QOps. Команда DataLabs повністю супроводжує клієнта в процесі встановлення та використання продукту, а також пропонує підтримку 24/7. Ми регулярно отримуємо зворотний зв’язок щодо використання QOps, що дозволяє нам подивитися на свій власний продукт очима користувача. Нижче ми підготували відповіді на найпоширеніші питання:

1. Чи зберігаються тригери та додаткові властивості для Qlik-додатків?

Так, зберігаються. Однак, варто врахувати, що деякі властивості вимагають збереження мінімальної моделі даних у додатку. Для цього у QlikView передбачено режим «reduce».

Для додатків Qlik Sense зберігається додаткове поле «always one selected». Для цього необхідно додатково зберігати відбори, оскільки це розходиться з концепцією QOps зберігати тільки вихідний код і властивості.

2. Чи можна мержити візуальну частину в Qlik Sense?

Ситуація, коли кілька розробників працюють на одному аркуші і кожен виконує свою частину роботи, можлива з QOps. Такий випадок підтримується QOps і для його реалізації необхідно дотримуватись грамотної стратегії гілок для уникнення мерж-конфліктів. Також варто приділити увагу правильному вирішенню мерж-конфліктів, якщо вони все ж виникли, щоб не порушити взаємодію з Qlik API.

3. Чи можлива робота з Bitbucket та Jenkins?

Та це можливо. Вихідні коди Qlik-додатку можуть бути розміщені в репозиторії Bitbucket, і за допомогою web-хуків CI/CD процес може бути побудований на основі Jenkins.

4. Чим відрізняється QOps від аналогів та які переваги його використання?

QOps в першу чергу орієнтований на реалізацію взаємодії з Qlik API та реалізацію CI/CD. Таким чином, QOps робить доступними в консолі всі команди, необхідні для роботи з програмами Qlik, а також забезпечує цілісність додатків при використанні додаткового коду в змінних або розширеннях.

Робота відомих аналогів здійснюється лише у браузері. Також варто зазначити, що на цей момент ними не підтримується CI/CD на різних хостинг-системах контролю версій на основі Git та пряма взаємодія користувача з вихідним кодом.

5. Чи можливо використовувати QOps для захисту коду в Qlik-додатках?

Так можливо. QOps дозволяє користувачам зберігати зміни у вихідному коді та керувати ними.

6. Чи можна перенести вихідний код програми QlikView до Qlik Sense за допомогою QOps?

Ні. Але є можливість керувати вихідним кодом QlikView і Qlik Sense за допомогою QOps.

7. Яка архітектура QOps і що потрібне для установки?

Установка QOps відбувається за допомогою інсталятора. Ми надаємо покрокову інструкцію для встановлення та використання продукту. Ознайомитись із документацією можна на сайті qops.datalabsua.com

У разі виникнення складнощів у процесі встановлення можна звернутися до служби підтримки QOps для оперативного вирішення проблеми.

8. Чи є тестовий період використання QOps?

Напишіть нам [email protected] чи заповніть форму на сайті qops.datalabsua.com

9. Модель та умови придбання QOps

Модель покупки являє собою пакет із 10 ліцензій. Реалізація CI/CD вимагає додаткової ліцензії на кожен ранер, де використовуватиметься QOps. Додатково потрібна ліцензія Qlik. Детальну інформацію можна отримати, заповнивши форму на сайті QOps.

Кожен клієнт особливий і має унікальні потреби. Якщо у вас залишилися питання – ми будемо раді відповісти на них:

[email protected]

+1 716 226 8951

+359 87 741 65 41

+44 2392 16 0664

+380 98 004 88 80

До будь-якого продукту додається інструкція з чітким зазначенням правил використання, застережень та ризиків, які можуть виникнути у випадку неправильного використання. Справедливо розповісти про деякі ризики неправильного використання QOps.

QOps відкриває розробникам шлях прямої модифікації вихідного коду Qlik.

Вихідні коди програм Qlik Sense побудовані з використанням JSON-об’єктів. JSON (JavaScript Object Notation) – це текстовий формат обміну структурованих даних на основі JavaScript. Цей формат також може бути використаний у будь-якій мові програмування.

Така структура вихідного коду програми Qlik Sense скорочує ризики завдати шкоди, що пояснюється можливістю розробника переглядати JSON-файли і вносити зміни до їхньої структури. Проте, ризики все ж таки існують:

1. Виникнення конфліктів при зміні тих самих рядків коду у різних гілках репозиторію. Наприклад, розмір сторінки може не співпадати з координатами розміщення об’єкта. В результаті виникає критична помилка API, яка не дозволяє QOps збирати додаток.
2. Блокування програми внаслідок злиття змін. Наприклад, користувач вносить зміни, які не підтримуються внутрішнім API Qlik.

Код QlikView побудований на xml-об’єктах та xml-даних. Неправильне використання QOps (наприклад, порушення цілісності контрольної суми, порушення логіки змін особливостей усередині xml-файлів) може призвести до неправильної роботи програми або повної зупинки роботи.

Уникнути це можна, використовуючи правильну стратегію розгалуження (докладніше про стратегію розгалуження тут), а також не допускаючи виникнення мерж-конфліктів. Вирішення таких конфліктів передбачає планування часу та наявність фахівця, який координуватиме всі зміни та безпосередньо керуватиме цим процесом.

Також варто відзначити, що розробник і користувач може не знати, як Qlik відреагує на певний фрагмент коду. Однак, грамотний підхід до процесу розробки, недопущення нових об’єктів або додавання нових об’єктів відповідно до API Qlik допоможе уникнути помилок.

Для вирішення будь-яких завдань та нюансів, які можуть виникнути у процесі використання QOps, існує служба підтримки 24/7. Команда фахівців оперативно виявляє помилку та знаходить рішення.

Більше інформації тут 

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

Безпека даних являє собою комплекс технологій для захисту даних від навмисного та випадкового знищення, зміни та розкриття даних. Більшість загроз для даних є зовнішніми, але не варто нехтувати внутрішньою системою захисту даних.

Методи захисту даних включають:

• шифрування даних;
• класифікація даних;
• визначення доступу до даних залежно від функцій та ролей;
• моніторинг та контроль переміщень та змін даних;
• створення резервних копій та відновлення даних.

Багато компаній віддають певну частину роботи на аутсорс. Досить поширена та зручна практика. Проте, вона потребує серйозного підходу до забезпечення безпеки даних. Компанії, які дбають про своїх клієнтів та цілісність даних, не нададуть жодному партнеру вільний доступ до даних. Особливого захисту потребують чутливі дані (інформація про клієнтів, банківська інформація, конфіденційна інформація тощо). Розробка та впровадження будь-якого BI-рішення повинна враховувати це.

Під час розробки QOps були враховані вимоги до безпеки даних. Захист даних та її підтвердження забезпечується у QOps за рахунок:

• поділ вихідного коду та даних (дані не зберігаються);
• керування правами доступу залежно від місця збереження вихідного коду.

Системи хостингу GitHub, GitLab, Bitbucket надають можливість налаштувати приватний чи публічний репозиторій. Приватний репозиторій передбачає доступ певним користувачам (учасники команди, адміністратор тощо), доступ до публічного репозиторію мають всі. Найчастіше у системах хостингу публічні репозиторії надаються через передплату. Приватний репозиторій із відповідними ключами передбачає платну основу.

У закритих системах з метою підвищення безпеки даних також виділяють окремі сервери для відкритих та конфіденційних даних (дані про клієнтів, номери телефонів, email тощо). Доступ до таких даних дуже обмежений. Для захисту персональних даних у Європі діє регламент (GDPR), який визначає правила та порядок обробки таких даних компаніями та організаціями. Будь-яка компанія, яка надає послугу або продає продукт громадянам Європейського Союзу, повинна дотримуватись цих вимог.

Для відповідності правилам GDPR та забезпечення захисту даних під час роботи QOps із захищеними Qlik-серверами передбачена можливість підключення через QOps Proxy. Таким чином, сертифікат, необхідний для підключення до API Qlik-сервера, розташований на тому ж конфіденційному сервері і не виходить за його межі. Це дозволяє запобігти ризикам підключення сторонніх користувачів, заволодіння сертифікатом і паролем, а також отримання доступу до даних у подальшому. Спеціальний метод аутентифікації за допомогою AzureAD дозволяє з’єднати робочу машину авторизованого користувача із QOps Proxy. Зі свого боку останній, використовуючи сертифікат, з’єднується з сервером і відправляє тільки ті дані та вихідний код, до яких користувач має доступ.

Повна архітектура взаємодії QOps встановленого на локальному комп’ютері користувача та QOps, встановлення у серверному оточенні, виглядає так. При цьому дотримуються вимоги безпеки даних та забезпечується гнучкість в керуванні вихідними кодами Qlik-додатків з використанням git-репозиторію, git-ранерів та зручного середовища розробки та редактора вихідних кодів VS Code.

Більше інформації ви знайдете на сайті QOps

Робочий процес розробника складається з безлічі різних завдань та проєктів. Для їх структурування та організації зручної роботи застосовуються трекінгові системи. Невеликі проєкти досить успішно використовують таблиці Excel для цього. Проте, з розвитком проєкту, зростає потреба впровадження зручнішого рішення.

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

На даний момент ринок пропонує досить багато варіантів трекінгових систем: Jira, Mantis, Trello, Redmine, PivotalTracker, Bugzilla, Commind тощо. Одним з найпопулярніших рішень є Jira.

Jira – це комплексне рішення від австралійської компанії Atlassian, до якого входить Jira WM (для роботи з бізнес-процесами), Jira SM (для побудови сервіс-диску), Jira Software (для проєктів із розробки програмного забезпечення). Разом ці продукти об’єднані у Jira Family Product.

Інструмент є платною системою з інтерактивним дашбордом для моніторингу переміщення завдань та контролю їх виконання у певному проєкті, а також є баг-трекінгом та зручним інструментом для управління проєктами, особливо для agile-команд. Основна мета Jira – спрощення керування робочим процесом. Система має широкий функціонал з можливістю доповнення його за допомогою плагінів. Існує пробна версія цього інструменту протягом 7 днів, що доступна на офіційному сайті розробника після реєстрації користувача.

Переваги Jira:

• Широкий функціонал (можливість адаптації інструменту до проєктів будь-якої складності);
• Великий потенціал інтеграції (можливість інтеграції з різними сервісами, такими як GitHub, Salesforce, Outlook, Slack, Gmail, Teams);
• Можливість розширення функціоналу за допомогою плагінів (Tempo, Script Runner, EazyBI, Big Picture, Structure);
• Можливість роботи методами Scrum та Kanban.

Варто відзначити досить тривалий процес налаштування інструменту під конкретний проєкт, робочі процеси та складний інтерфейс. Причиною є широкий функціонал системи. Однак, вивчення інструменту та регулярна практика дозволяють якісно налаштувати його та оптимізувати у процесі використання.

Можливості Jira в залежності від команд, ролей та цілей використання:

• Проєктний менеджер (PM): чудовий помічник для роботи проєктного менеджера. Проте, досить складний і багатогранний інструмент вимагає детального вивчення для ефективного використання його функцій. Використовуючи можливості інструменту, PM отримує можливості запропонувати цікаві ініціативи для оптимізації процесів. Офіційна сертифікація Jira підвищує конкурентоспроможність фахівця;
• Для команд управління проєктами: можливість використовувати готовий шаблон, який пропонує інструмент або створити власний процес з можливістю відстеження всіх завдань, їхній шлях по всіх стадіях процесу до завершення. Адміністратор має можливість налаштовувати доступ із різними правами для різних користувачів. Також інструмент дозволяє створювати детальні звіти за наявності інформації про проєкт;
• Для команд розробки програмного забезпечення: наявність інструментів для планування дозволяє учасникам управляти бюджетами та вимогами. Jira інтегрується з різними інструментами CI/CD. Це сприяє прозорому веденню всього циклу розробки ПЗ. Поступове та безпечне впровадження нової функціональності забезпечується за рахунок вбудованих функцій включення та відключення можливостей;
• Для команд DevOps: основою відкритого інтегрованого комплекту інструментів Atlassian є Jira Software. Інструмент інтегрується з власними та сторонніми інструментами, а також з рішеннями для керування кодом (Bitbucket, GitHub, GitLab), інструментами керування документацією та знаннями (Confluence), інструментами моніторингу та керування тощо. Така гнучкість інструменту прискорює постачання якісного ПЗ;
• Для команд керування продуктами: команди мають можливість створювати roadmap для всіх проєктів. Це дозволяє складати довгострокові плани, відстежувати прогрес та ділитися інформацією;
• Для відстеження помилок: завдання (баги/проблеми, які виникають у процесі розробки ПЗ) можна побачити в беклозі та визначити їхню пріоритетність. Автоматичне визначення пріоритетності проблем після їх виявлення забезпечується системою керування робочим процесом у Jira;
• Для керування завданнями: створення завдань для всіх учасників команди, додавання детальної інформації, термінів виконання та нагадувань. Є можливість розділити великі завдання на кілька дрібних, створювати підзавдання для певних учасників команди. Інші користувачі можуть відстежувати виконання завдань та отримувати повідомлення після їх вирішення. Поточний стан завдань можна подивитися за допомогою дашборда.

З точки зору використання при керуванні Qlik-проєктами дуже зручною є можливість інтеграції трекінгової системи та хостингу віддаленого git-репозиторію. В якості сполучної утиліти між вихідним кодом в репозиторії та кінцевим додатком може використовуватися QOps. Така інтеграція дозволяє автоматично впроваджувати у вихідний код програми посилання на завдання в трекінговій системі. З точки зору управління процесом розробки така можливість дозволяє менеджменту відслідковувати просування тікетів та відповідну цьому міграцію вихідного коду між оточеннями та/або версіями.

Більше інформації за посиланням

CI/CD пайплайни допомагають мінімізувати потенційні ризики в процесі інтеграції змін коду в репозиторій, ізолювати вплив можливих помилок та спрощувати їх виправлення. Головне завдання CI/CD – прискорити процес розробки та надання цінності кінцевому користувачеві. Проте, завжди існують шляхи та інструменти, як зробити процес ще ефективнішим. Матричний підхід є одним із таких варіантів.

Базова структура пайплайна передбачає одночасне виконання завдань на певному етапі. При цьому завдання наступного етапу можуть бути виконаними за умов завершення попередніх. Цей процес продовжується на всіх етапах. Різні завдання у конвеєрі потребують різний час для їхнього виконання. Учасникам команди доводиться чекати, аби внести свої зміни до проєкту. Це значно уповільнює робочий процес та знижує продуктивність. Також, наявність однакових конвеєрів та сценаріїв створення можуть призвести до блокування пайплайнів. Для оптимізації ресурсів та підвищення продуктивності існує сенс створення клонів завдань та паралельного їх запуску.

Раніше необхідно було вручну визначати завдання для їхнього паралельного виконання. З появою паралельних матричних завдань з’явилась можливість створювати завдання під час виконання на основі зазначених змінних.

Матрична стратегія використовує змінні під час визначення завдання, що дозволяє забезпечити автоматичне створення кількох виконань завдань. Ця стратегія може використовуватися в процесі тестування коду у різних варіантах мови та/або різних операційних системах. Матриця може бути створена з різними конфігураціями завдань із зазначенням однієї чи більше змінних. Визначаючи змінні (одну чи кілька), завдання застосовуватиметься для кожної комбінації змінних.

Варто звернути увагу на певну особливість. Вона полягає в тому, що організації часто використовують монорепозиторії для кращого управління проєктами. Проте, продуктивність конвеєра знижується в ситуації, коли в репозиторії знаходиться велика кількість проєктів і одне визначення конвеєра використовується для запуску різних автоматизованих процесів для різних компонентів. Використання батьківських та дочірніх конвеєрів сприяють створенню ефективних конвеєрів. Такий підхід мінімізує можливість виникнення конфліктів злиття, дозволяє редагування частини конвеєра за необхідністю.

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

Архітектура комплексного Qlik-додатка складається з кількох шарів (трансформери, модель, дашборд та екстрактори). І при використанні QOps, матрична стратегія якнайкраще підходить для управління однотипними додатками в межах одного шару. До таких можна віднести додатки у шарі трансформерів та екстракторів.

GitHub, GitLab та Jenkins дозволяють будувати пайплайни на основі матричної стратегії, яка перебирає наявні завдання згідно з декартовим множенням. Це зроблено для розширення можливостей CI/CD, а саме у проведенні тестування на різних платформах або, наприклад, із різними версіями фреймворків.

На скріншоті нижче відображено приклад вихідного файлу пайплайну для GitHub, перевантаження трансформерів в якому реалізовано з використанням матричної стратегії. Ключовим словом для цього є matrix у блоці strategy. Необхідний перелік програм вказується у вигляді списку у рядку 403. При цьому підстановка програми, що ітерується, буде виконана при кожному згадуванні matrix.app.

Так виглядає список додатків, що використовуються в графічному інтерфейсі GitHub при виконанні пайплайна. При цьому легко виконується масштабування кількості додатків, що обробляються. Для цього достатньо лише змінити їх список і не вносити зміни до виконуваної частини коду.

Більше інформації ви знайдете за посиланням