#qops

Найчастіші питання про QOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Модель та умови придбання 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.

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. Команда фахівців оперативно виявляє помилку та знаходить рішення.

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

Місце QOps в організації безпечного доступу до даних

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

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

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

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

Інтеграція трекінгової системи з git-репозиторієм

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

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

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

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

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

Переваги Jira:

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

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

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

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

DevOps підходи до опрацювання великої кількості тестів та додатків

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

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

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

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

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

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

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

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

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

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

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

Вибір сервіс провайдеру для менеджменту Qlik-проєктами

Git – це розподілена система контролю версіями файлів та спільної роботи, яка була розроблена у 2005 році Лінусом Торвальдсом. У перекладі з англійської назва «git» означає «негідник». Розробник пояснює таку назву з часткою сарказму: «Я егоїстичний негідник, а тому всі проєкти називаю на свою честь. Спочатку Linux, тепер – git».

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

Крім комфортної роботи, гнучкості та можливості вести історію розробки, використання Git значно знижує появу помилок у розробці та втрату даних. Подібними SCM-системами управління версіями є Mercurial, Subversion, Darks, Bazaar. Однак, Git має ряд переваг:

Основні завдання Git:

Використання Git здійснюється за допомогою спеціальних хостингів та репозиторіїв.

GitHub був створений у 2008 році, а в 2018 році його викупила корпорація Microsoft за $7,5 млрд. GitHub являє собою хостинг вихідного коду, а також велику соцмережу розробників з 20 млн користувачів, які можуть переглядати коди один одного, допомагати в розробці та залишати коментарі, та 80 млн репозиторіїв по всьому світу. Користувачі можуть створювати свій репозиторій і публікувати свої роботи. Безкоштовне використання можливе лише для публічних проєктів з відкритим кодом. Платформа написана на Ruby on Rails і має велику кількість загальнодоступних проєктів із відкритим кодом.

Переваги GitHub:

GitLab є альтернативою GitHub, а також веб-сховищем з наданням безкоштовних відкритих і приватних сховищ. GitLab був розроблений двома українцями: Дмитром Запорожцем та Валерієм Сизовим, використовуючи Ruby та деякі частини Go. Пізніше архітектура була вдосконалена за допомогою Go, Vue.js та Ruby on Rails.

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

Переваги GitLab:

BitBucket – аналог GitHub, який призначений для хостингу проєктів та їхньої спільної розробки. Сервіс був розроблений австралійською компанією Atlassian, яка створила Jira та Confluence. Він дозволяє безкоштовно створювати відкриті та закриті репозиторії на основі технологій Git, має можливість інтегруватися з Jira та Snyk та вбудованими можливостями CI/CD. Сервіс є чудовим рішенням для невеликих команд.

Переваги BitBucket:

Jenkins є системою з відкритим кодом на основі Java. Вона забезпечує автоматизацію елементів процесу розробки ПЗ без залучення людей і безперервної інтеграції ПЗ. Jenkins широко використовується в компаніях, де є потреба в автоматичному деплойменті додатків. Система безкоштовна, працює на Windows, macOS та інших Unix-подібних ОС, а також має інтеграцію з Docker та Kubernetes. Jenkins не містить репозиторію з вихідним кодом, а підключається до вже наявних через веб-хуки. Отже, це універсальний інструмент для CI/CD незалежно від вибраного хостингу віддалених репозиторіїв.

Переваги Jenkins:

QOps може ефективно працювати з усіма перерахованими сервісами.

GitHub і GitLab включають можливість встановлення ранерів, які в подальшому будуть виконувати команди з .yml файлу, включеного до репозиторію вихідних кодів при досягненні певної події. Як правило, такою подією є відправлення вихідних кодів (push) або злиття гілок (merge) у віддаленому репозиторії. При цьому синтаксис складання .yml файлів трохи відрізняється, хоча описує ту ж саму сутність поведінки ранера та управління процесом складання програми, тестування та подальшого розгортання. Обидві хостингові системи дозволяють встановлювати свої ранери в оточенні Windows, що поки не доступно для хостингу BitBucket.

Покажемо детальніше використання QOps з вищезгаданими системами. Для GitHub .yml файл є структурованим набором етапів, який складається з послідовних кроків. У наведеному нижче прикладі описується 3 етапи – init-build-reload.

Такий вигляд має цей пайплайн за умов його успішного виконання.

Для GitLab .yml файл являє собою такий самий структурований набір етапів. Відмінностями є інше найменування ключових слів і гнучкіша робота зі змінними. На жаль, розробники не використовують уніфікований формат .yml файлу та взаємна сумісність між ними не забезпечується.

При успішному виконанні вид пайплайну, що складається з тих самих етапів представлений нижче. Тут варто відзначити, що GitLab має більш розвинену інтерактивність. Наприклад, у пайплайні можна налаштувати ручне підтвердження від користувача.

Оскільки QOps зараз працює виключно в середовищі Windows, то автоматичний пайплайн, у разі вибору BitBucket для хостингу вихідних кодів, може бути розроблений при використанні Windows-версії Jenkins. Універсальність останнього та різноманітність плагінів дозволяє пов’язати будь-який віддалений репозиторій через веб-хуки. Структура пайплайна у разі налаштування через інтерфейс самого Jenkins записується у вигляді JSON-об’єкта, і для нашого прикладу містить ті самі 3 етапи – Configuration-Build-Reload.

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

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

Branching strategy при реалізації масштабних Qlik-проєктів

Швидкість та гнучкість розробки ПЗ відіграють важливу роль. Однак, за одночасної роботи великої команди розробників код розгалуження та злиття може стати безладним. Такі команди необхідно забезпечити процесом одночасного впровадження змін. Ефективна стратегія розгалуження (branching strategy) є пріоритетом у вирішенні цього питання.

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

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

Стратегія розгалуження дозволяє:

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

Гілки в Git представлені тегами чи покажчиками. Усі зміни відстежуються у вигляді спрямованого ациклічного графа, кожен вузол якого є набором змін, зроблених одночасно. Гілки Git надають розробникам можливість відхилятися від основної гілки та створювати окремі гілки для ізоляції змін коду. Гілкою за замовчуванням у Git є «main branch»”. Головною перевагою гілки Git є її «незначна вага». Тобто, дані складаються із серії знімків і при кожній фіксації змін Git робить знімок поточного стану файлів і зберігає посилання на нього. Такі гілки є не просто копіями, а й покажчиком на останній коміт.

Основні стратегії розгалуження Git:

Приклад мердж-конфлікту та його вирішення

Розглянемо приклад виникнення мердж-конфлікту та можливі способи його вирішення з використанням QOps для контролю версій програми Qlik Sense. Для цього візьмемо Qlik Sense додаток і за допомогою QOps створимо репозиторій вихідних кодів та 2 гілки dev1 та dev2 для окремих розробників. Уявимо ситуацію, коли кожен із розробників змінив якийсь загальний елемент (наприклад, колір фону об’єктів з виведенням KPI значень).

Оскільки на рівні вихідних кодів зміни відбулися в тих самих рядках, при виконанні злиття dev1 -> master і dev2 -> master, в останньому виникає мердж-конфлікт. Вирішення мердж-конфлікту вимагає прийняття рішення, який саме з варіантів повинен бути присутнім у зведеному варіанті. Засіб розробки VSCode дозволяє в інтерактивному режимі ухвалити це рішення. Однак, це накладає додаткову відповідальність на IT-фахівця, який виконає це злиття.

Існує ризик отримати від обох розробників частини коду для загального елемента в кінцевому додатку, які можуть бути несумісними. Наприклад, після злиття можна отримати наступний результат, коли для першого об’єкта було обрано рішення Accept Incoming, а для другого – Accept Current.

Зручно проводити злиття вихідних кодів, використовуючи веб-інтерфейс систем контролю версій. Нижче наведено хід виконання Pull Request у GitHub при безконфліктному злитті.

Наявність конфліктних змін призводить до виводу відповідного попередження та додаткової інформації.

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

Розв’яжемо наявний конфлікт протилежно описаному вище. У результаті отримуємо очікуваний результат із протилежним кольоровим розфарбуванням загальних елементів.

Детальная інформація пhо QOps тут

Переваги використання CI/CD при розробці Qlik додатків

Безперервна інтеграція (СI – Continuous Integration) та безперервна доставка (CD – Continuous Delivery) є однією з типових практик DevOps, що дозволяє розробникам надійно та оперативно розгортати зміни програмного забезпечення. Ключова відмінність від ручної розробки полягає саме в автоматизації тестування та складання коду.

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

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

Розглянемо детальніші основні аспекти концепції CI/CD як практики DevOps

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

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

Перевага CI/CD полягає у скороченні часових витрат на розробку програмного продукту, мінімізації та виявленні помилок та дефектів на ранніх етапах створення коду, скороченні часу на виправлення помилок, скорочення циклів зворотного зв’язку.

Наприклад, є сайт, що відображає аналітику продажу деякої компанії. Архітектура цього рішення включає бекенд (може бути представлений базою даних з певним ETL-процесом для обробки даних) та фронтенд (у разі використання технології Qlik – фронтенд забезпечується встановленим веб-сервером). У процесі розробки та оновлень окремими розробниками вносяться зміни до однієї або до кількох частин. Потім зміни об’єднуються в репозиторії лише на рівні вихідних кодів, проходять весь пайплайн і, зрештою, зміни відображаються відразу у всьому продукті.

Етапи циклу CI/CD:

  1. Створення (написання певної частини коду та наступне тестування; після успішного тестування частини коду з’єднуються в одне ціле та переносяться у робочу гілку розробки);
  2. Складання (реалізація контролю версій з використанням Git, автоматичного складання з урахуванням змін та тестування отриманого коду);
  3. Тестування (реалізація перевірки коду командою тестувальників);
  4. Реліз (успішне проходження коду продовжується перенесенням коду в реліз, створення робочого складання оновлення поточної версії продукту до актуальної версії);
  5. Розгортання (трансляція поновлення на серверах розробників для оновлення програмного забезпечення до останньої версії);
  6. Підтримка (моніторинг відгуків користувачів);
  7. Планування (створення списку змін для майбутніх версій).

Використання QOps у життєвому циклі розробки Qlik-додатку

Зазвичай автоматизація процесів інтеграції та розгортання виконується встановленим GitHub/GitLab ранером, який інтегрований із репозиторієм. Інструменти автоматизації Bitbucket також можуть інтегруватися з трекінговою системою Jira, що спрощує процес управління завданнями, дає можливість бачити в якій галузі репозиторія знаходиться потрібне оновлення і стежити за подальшим його просуванням. Для отримання команд від ранера QOps має бути встановлений на одному з ним сервері. Це дає можливість включати команди QOps у пайплайн інтеграції та розгортання програм Qlik.

Переваги використання QOps:

Приклад застосування QOps у пайплайні інтеграції та розгортання комплексного Qlik-додатку

Для автоматизації процесів підтримки та оновлення комплексного Qlik-додатку одного з клієнтів компанії за допомогою GitHub Actions інтегровано наступний пайплайн.

Qlik-додаток має 4-х шарову структуру (трансформери – модель – дашборд – екстрактори) та виконано в архітектурі QlikView.

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

Нижче наведено активні етапи, які будуть виконані у разі використання гілки з ім’ям UAT-*. Завдання такого підходу вже під час створення нової гілки підготувати необхідні файли в окремій папці для пробного розгортання нового завдання.

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

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

Такий результат виконання послідовних кроків пайплайна в межах одного етапу. Деякі кроки, залежно від поставлених умов, також можуть бути пропущені, ігноровані або зупинені у разі виявлення помилок.

У разі виникнення помилки виконання пайплайн сигналізуватиме про це наступним чином.

Для більш детального вивчення кожного кроку виконання на кожному етапі доступний консольний висновок, завдяки якому зручно відстежувати і усувати помилки.

Отже, варто зазначити, що впровадження CI/CD у процес розробки та підтримки Qlik-додатку скоротило витрачений час на зведення результатів паралельної розробки та значно спростило процес підготовки додаткових файлів для подальшого розгортання.

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

QOps: ключові переваги використання

Компанія Qlik є одним із лідерів серед провайдерів BI-систем. Його головні продукти – QlikView та Qlik Sense (інструменти для аналізу та візуалізації даних, що надають можливість отримувати та досліджувати дані з різних джерел). Користувачі Qlik можуть самостійно розробляти об’єкти візуалізації (звіти, моделі даних, аналітичні програми тощо) без участі IT-фахівців. Рішення Qlik є доцільними для різних сценаріїв використання, наприклад:

Однак, цьому передує ємний процес розробки Qlik-додатка з урахуванням індивідуальних потреб і запитів бізнесу. Консольний інструмент QOps, розроблений компанією DataLabs, призначений для вирішення ряду завдань у процесі розробки, контролю версій та подальшого розгортання Qlik-додатків.

Розробка

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

Також QOps дозволяє скоротити рутинну ручну роботу розробників під час розгортання та пошуку помилок. Наприклад, кілька розробників працюють над одним додатком, кожен із яких розробляє свою частину. Тоді для створення одного цілого проєкту розробникам необхідно домовлятися, як будуть внесені зміни від кожного розробника. Проблема також полягає в тому, що 2 окремі готові частини можуть не працювати разом. QOps автоматизує цей процес за допомогою репозиторіїв GitLab, GitHub або Bitbucket, де відбувається злиття, перевірка на наявність конфліктів та, у разі потреби, їх вирішення. Таким чином, у розробника немає необхідності тримати всі зміни в голові, щоб реалізувати певне завдання чи функціонал. Важливо, що розробник – це звичайна людина, якій властиво іноді припускатися помилок. Будь-який ручний процес, зокрема розгортання, підвищує ризик допущення помилок. QOps, зі свого боку, допомагає не допустити цього.

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

Розгортання

Завдяки QOps можливе спрощення процесу розгортання і навіть розгортання додатків без детальних знань особливостей його розробки. Це зможе виконати тімлід або проєкт-менеджер або девопс. Користувач також може використовувати плейсхолдери у вихідному коді, які будуть автоматично підставлені під час міграції вихідних кодів між середовищами або клієнтами. Це гарантує коректне автоматичне розгортання без будь-яких особливостей та змін вручну. Зі свого боку, це скорочує витрати часу на розгортання та відкриває можливість для пошуку нових ідей та/або створення нового продукту.

Контроль версій

Основним завданням системи контролю версій є запис змін у файлі або наборі файлів у певний період часу. Це дозволяє користувачеві в будь-який момент повернутися до певної версії, повернути вибрані файли або весь проєкт у попередній стан, відстежити зміни та його автора, за необхідності виправити помилки. Система контролю версій дозволяє розділити вихідний код на гілки (окремі частини розвитку продукту). У процесі розробки вони можуть зливатись (Development →Master), відокремлюватися в окремий продукт, що забезпечує повну свободу дій кожного розробника та кожної версії. Важливо, що контроль має за основу певну версію і фіксує лише зміни, а не цілу версію. QOps дозволяє отримувати код з розроблених Qlik-додатків, поміщати в репозиторій у якусь гілку, накопичувати зміни та досліджувати їх (відстежити зміни, помилки, автора змін тощо). QOps є проміжним інструментом між Qlik та сучасними системами контролю версій на основі Git.

Процедура установки QOps досить проста, проте передбачає деякі вимоги:

Приклад злиття спільної розробки Qlik Sense додатку

Створимо новий додаток в Qlik Sense. В якості моделі даних використовуємо синтетичний набір значень, який заданий у вигляді таблиці за допомогою оператора INLINE.

В частині візуалізації створюємо чернетку майбутнього дизайну листа.

Збережемо додаток і за допомогою QOps вилучимо вихідний код нового додатку та розмістимо його у GIT-репозиторій в основній гілці. Розділимо подальшу розробку додатку на 2 розробників. Їм відповідають гілки dev1 та dev2. Перший розробник займається лівою частиною листа, де він оформив стовпчасту діаграму та таблицю під нею.

У цей час другий розробник займається оформленням правої частини листа, де дані візуалізовані за допомогою кругової діаграми у форматі «пончик» та діаграми розкиду.

Після закінчення роботи кожний з розробників зробив відповідні коміти у свої гілки. Тепер по черзі виконуємо злиття основної гілки репозиторію з dev1 та dev2.

Нижче цей процес у середовищі розробки Visual Studio Code. Використання чернетки з запланованих візуальних компонентів забезпечує відсутність конфліктів та автоматичне виконання злиття.

Після злиття та подальшого складання повністю оформлений лист додатку відображатиме результати роботи обох розробників.

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

Принципи роботи QOps

Основна проблема, яку вирішує QOps – це складність застосування системи контролю версій GIT до кінцевого файлу розробки, який містить дані, модель даних, код завантаження даних, коди всіх чартів та об’єктів візуалізації.

Що таке GIT?

GIT є системою контролю версій, яка допомагає відстежити внесені в базу коду зміни, визначити користувача, який їх вніс, і відновити віддалений або змінений код. На даний момент GIT є однією з найпопулярніших систем контролю версій з відкритим кодом і дуже простим у використанні. Також, GIT є повністю безкоштовним ПЗ та підтримує різні ОС (Vac, Windows, Linux, Solaris).

Перевагами GIT є:

Як застосувати GIT у процесі розробки Qlik-додатків?

Проблеми паралельної розробки додатків, відстеження змін у вихідному коді, процесу розробки за участю більше 1 розробника, ручного видалення коду та чартів вирішують GitLab та GitHub. Однак, якщо розмістити файл Qlik Sense/QlikView на GitLab – результату це не дасть. Цей файл потрібно розділити на окремі частини: код, налаштування чартів тощо, і після цього зібрати ці частини назад у файл. Автоматизувати процес розбору та збору додатку допомагає QOps.

Як працює QOps?

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

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

QOps дозволяє:

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

GoUp Chat