#qops

Frequently asked questions about QOps

In September 2022, we introduced our own product QOps. DataLabs team fully accompanies the client during the installation and use of the product and offers 24/7 support. We regularly receive feedback regarding QOps usage, that allows us to look at our own product through the user’s eyes. Below we have prepared answers to the most common questions:

  1. Are triggers and additional properties saved for Qlik apps?

Yes. However, it is worth considering that some properties require a minimal data model to be maintained in the application. To do this, QlikView provides a «reduce» mode.

For Qlik Sense apps, an additional «always one selected» field is retained. To do this, it is necessary to save selections additionally, since this is a bit at odds with the concept of QOps to save only the source code and properties.

  1. Is it possible to merge the visual part in Qlik Sense?

The situation when several developers work on the same sheet, and everyone does own part of the work is possible with QOps. For its implementation it is necessary to adhere to a competent branch strategy to avoid merge conflicts. It is also worth paying attention to the correct resolution of merge conflicts in case occur to not disrupt interaction with the Qlik API.

  1. Is it possible to work with Bitbucket and Jenkins?

Yes, it is possible. Source codes for a Qlik application can be hosted in a Bitbucket repository, and with the help of CI/CD web-hooks, a process can be built on top of Jenkins.

  1. How does QOps differ from analogues and what are the advantages of using it?

QOps is primarily focused on the implementation of interaction with Qlik API and CI/CD implementation. Thus, QOps makes available in the console all the commands necessary to work with Qlik applications and ensures the integrity of applications when using additional code in variables or extensions.

The work of analogs is carried out only in the browser. It is also worth noting that they currently don’t support CI/CD across Git-based version control hosting systems and direct user interaction with the source code.

  1. Is it possible to use QOps to protect code in Qlik applications?

Yes, it’s possible. QOps allows users to save and manage changes to source code.

  1. Is it possible to migrate source code of a QlikView application to Qlik Sense using QOps?

No. But it is possible to manage the source code of both QlikView and Qlik Sense with QOps.

  1. What is QOps architecture and what is required for installation?

QOps is installed using the installer. We provide step by step instructions for installing and using the product. You can find the documentation at qops.datalabsua.com

If you encounter difficulties during the installation process, you can contact QOps support for a prompt solution to the problem.

  1. Is there a trial period for using QOps?

Email us [email protected] or fill out the form at qops.datalabsua.com

  1. Model and conditions for purchasing QOps

The purchase model is a pack of 10 licenses. CI/CD implementation requires an additional license for each runner where QOps will be used. Additionally, a Qlik license is required. Detailed information can be found by filling out the form on QOps website.

Each client is special and has unique needs. If you have any questions, we will be happy to answer them:

[email protected]

+1 716 226 8951

+359 87 741 65 41

+44 2392 16 0664

+380 98 004 88 80

Risks of QOps misuse

Each product is accompanied by instructions that clearly indicate the rules of use, warnings and risks that may arise in case of improper use. It’s fair to talk about some of misusing QOps risks.

QOps opens the way for developers to directly modify the Qlik source code.

The source codes for Qlik Sense applications are built using JSON objects. JSON (JavaScript Object Notation) is a text-based structured data interchange format based on JavaScript. This format can also be used in any programming language.

This structure of the application source code in Qlik Sense reduces the risk of damage, which is due to the developer’s ability to revise JSON files and make changes to their structure. However, risks still exist:

  1. The occurrence of conflicts when changing the same lines of code in different branches of the repository. For example, the page size may not match the placement coordinates of the object. The result is a critical API error that prevents QOps from building the application.
  2. Blocking the application as a result of merging changes. For example, the user makes changes that are not supported by Qlik’s internal API.

QlikView code is built on xml objects and xml data. Incorrect use of QOps (for example, violation of checksum integrity, violation of changes logic in features inside xml files) can lead to incorrect operation of the application or a complete stop of work.

This can be avoided by using the correct branching strategy (read more about the branching strategy here), as well as avoiding merge conflicts. The solution of such conflicts involves time planning and the presence of a specialist who coordinates all changes and directly manages this process.

It is also worth noting that the developer and user may not know for sure how Qlik will perceive a particular piece of code. However, a good approach to the development process, avoiding new objects or adding new objects in accordance with Qlik API will help to avoid errors.

To solve any problems and nuances that may arise in the process of using QOps, there is a 24/7 support service. A team of specialists quickly identifies errors and finds a solution.

More information here

QOps place in secure data access ensuring

In the modern world, data is the most valuable resource that opens new opportunities for development, new ideas and efficient operations. Its value creates high cybercriminals’ interest who steal or corrupt data for their own benefit. Their methods are becoming more sophisticated and inconspicuous, and the consequences become more serious, that incur large financial and reputational losses. The issue of data security is of key importance and is not bypassed by standard security programs.

Data security is a technology set for protecting data from intentional and accidental destruction, alteration and disclosure of data. Most data threats are external, however, don’t neglect the internal data protection system.

Data protection methods include:

Many companies outsource some of their work. It’s a common and convenient practice. But  it requires a serious approach to ensuring data security. Companies that care about their customers and data integrity will not give any partner free access to data. Sensitive data (customer information, banking information, confidential information, etc.) needs special protection. The design and implementation of any BI solution must take this into account.

When developing QOps, data security requirements were considered. Data protection and validation is ensured in QOps by:

GitHub, GitLab, Bitbucket hosting systems provide the ability to set up a private or public repository. A private repository implies access to certain users (team members, administrator, etc.). In the situation with public repository everyone has access. Often in hosting systems, public repositories are provided through a subscription. A private repository with corresponding keys assumes a paid basis.

In closed systems, in order to increase data security, separate servers are also allocated for public and confidential data (customer data, phone numbers, email, etc.). Access to such data is severely limited. To protect personal data in Europe, there is a regulation (GDPR), that determines the rules and procedures for such data processing by companies and organizations. Any company that provides a service or sells a product to citizens of the European Union must comply with these requirements.

To comply with GDPR rules and ensure data protection when QOps works with secure Qlik servers, it is possible to connect through QOps Proxy. Thus, the certificate required to connect to the Qlik Server API is located on the same confidential server and does not go beyond it. This prevents the risks of third-party users connecting, taking possession of the certificate and password, as well as gaining access to data in the future. A special authentication method using AzureAD allows to connect the authorized user’s work machine to the QOps Proxy. In turn, the latter, using a certificate, connects to the server and sends only the data and source code to which the user has access.

The complete architecture of the interaction between QOps installed on the user’s local computer and QOps installed in the server environment is as follows. As you can see, this complies with data security requirements and provides flexibility in managing the source codes of Qlik applications using a git-repository, git-runners and a convenient development environment and source code editor VS Code.

More information you will find on QOps website

Tracking system integration with git repository

Developer’s workflow consists of many different tasks and projects. Tracking systems are used to structure them and organize convenient work. Small projects use Excel spreadsheets quite successfully for this purpose. However, project development requires more convenient solution implementation.

A tracking system is a software product, project management system that ensures the fulfillment of tasks, workflow planning, monitoring processes and results. This tool is useful for all team members: developers, project managers, team leads, top management, etc.

Now, the market offers large number of options for tracking systems: Jira, Mantis, Trello, Redmine, PivotalTracker, Bugzilla, Commind, etc. One of the most popular solutions is Jira.

Jira is a comprehensive solution from the Australian company Atlassian, which includes Jira WM (for working with business processes), Jira SM (for service disk building), Jira Software (for software development projects). These products are grouped into the Jira Family Product.

This tool is a paid system with an interactive dashboard for monitoring tasks movement and controlling their progress in a specific project. It is also a bug tracking and a convenient tool for project management, especially for agile teams. The main Jira goal is to simplify workflow management. The system has a wide functionality with the ability to supplement it with the help of plugins. There is a trial version of this tool for 7 days, which is available on the developer’s official website after user registration.

Jira benefits:

It is worth noting the rather long tool setting process for a specific project, workflows and a complex interface. The reason for this is the wide functionality of the system. However, tool study and practice allow to fine-tune it and optimize it during use.

Jira features depending on teams, roles and purposes of use:

The ability to integrate a tracking system and host a remote git repository is very convenient in managing Qlik projects. QOps can be used as a bridge between the source code in a repository and the final application. This kind of integration allows to automatically embed links to tasks in the tracking system into the source code of the application. As well as this feature allows management to track the progress of tickets and the corresponding source code migration between environments and/or versions.

More information at the link

DevOps approaches to process a large number of tests and application

CI/CD pipelines help to minimize potential risks in the process of integrating code changes into the repository, isolate the impact of possible errors and simplify fixing process. The main CI/CD goal is to speed up development process and value delivery to the end user. However, there are always ways and tools to make the process even more efficient. The matrix approach is one such option.

The basic pipeline structure involves the execution of tasks simultaneously at a certain stage. Tasks at the next stage can be completed if the previous ones are completed. This process continues at all stages. Different tasks in a pipeline take different times to complete. So, team members must wait to make their changes to the project. This significantly slows down the workflow and reduces productivity. Also, the presence of the same pipelines and creation scripts can lead to pipelines blocking. To optimize resources and increase productivity, it makes sense to create tasks clones and run them in parallel.

Previously, it was necessary to manually define tasks for their parallel execution. With the advent of parallel matrix jobs, it became possible to create jobs at runtime based on specified variables.

The matrix strategy uses variables when defining a job and allows to provide automatic creation of multiple job executions. This strategy can be used in the process of testing code in different languages and/or different operating systems. The matrix can be created with different job configurations specifying one or more variables. By defining variables (one or more), task will be applied for each variable combination.

It is also worth considering one feature. So, organizations often use mono-repositories for better project management. However, pipeline performance is degraded when there are many projects in the repository and one pipeline definition is used to run different automated processes for different components. Using parent and child pipelines makes pipelines more efficient. This approach minimizes the chance of merge conflicts and allows editing of pipeline parts if necessary.

On the one hand, pipelines optimization reduces the time developers spend on maintenance. On the other hand, it frees up time and space for new ideas, creativity and increased productivity. For example, using a matrix, it is possible to break down large pipelines into manageable parts for more efficient maintenance and maximization of tasks amount that run in parallel. The order in which jobs are created dictates the order of the variables in the matrix. The first variable is the first job in the run.

The complex Qlik application architecture consists of several layers (transformers, model, dashboard and extractors). And when using QOps, the matrix strategy is the best suited for managing applications of the same type within the same layer. These include applications in the layer of transformers and extractors.

GitHub, GitLab and Jenkins allow to build pipelines based on a matrix strategy that iterates over the available tasks according to cartesian multiplication. This was done to expand CI/CD capabilities, namely in testing on different platforms or, for example, with different frameworks versions.

The screenshot below contains an example pipeline source file for GitHub, where transformer overloading is implemented using a matrix strategy. The keyword for this is matrix in strategy block. The required list of applications is specified as a list on line 403. In this case, the substitution of the iterated application will be performed each time matrix.app is specified.

This is how used applications list in GitHub graphical interface looks like when executing the pipeline. At the same time, scaling the number of processed applications is easily performed. To do this, it is enough just to change their list and not make changes to the executable part of the code.

More information you will find at the link

Choosing a service provider for Qlik projects management

Git is a distributed file version control and collaboration system that was developed in 2005 by Linus Torvalds. The developer explains its name (git) with a bit of sarcasm: «I am a selfish scoundrel, and therefore I name all projects after myself. First Linux, now git.»

Now Git is the most popular and free tool that is a set of command line utilities. It allows to track the history of software development and work with entire teams from anywhere in the world on one project. Each change is added in the form of commits that allows to track, revert the change if it’s necessary and revert to previous versions.

In addition to being comfortable, flexible, and able to maintain development history, using Git greatly reduces development errors and data loss. Similar SCM version control systems are Mercurial, Subversion, Darks, Bazaar. However, Git has some advantages:

Git main tasks:

The use of Git is carried out with the help of special hosting and repositories.

GitHub was created in 2008 and bought out by Microsoft for $7.5 billion in 2018. GitHub is a source code hosting site and a large social network for developers with 20 million users who can view each other’s code, help to develop, and leave comments, and 80 million repositories worldwide. Users can create their own repository and publish their work. Free use is possible only for public open-source projects. The platform is written in Ruby on Rails and has a large number of open-source projects available to the public.

GitHub benefits:

GitLab is an alternative to GitHub and is a web repository that provides free public and private repositories. GitLab was developed by 2 Ukrainians: Dmitry Zaporozhets and Valery Sizov, using Ruby and some parts of Go. The architecture was later enhanced with Go, Vue.js and Ruby on Rails.

GitLab is a complete DevOps platform for project planning, source code management, monitoring, security, and more. It also offers wiki hosting and a bug tracking system. Using GitLab significantly shortens the product life cycle and increases productivity. This, in turn, adds value to the customer.

Gitlab benefits:

BitBucket is an analogue of GitHub that is designed for hosting projects and their joint development. The service was developed by the Australian company Atlassian, which created Jira and Confluence. It allows to create public and private repositories based on Git technologies for free, has the ability to integrate with Jira and Snyk, and built-in CI/CD capabilities. The service is a great solution for small teams.

BitBucket benefits:

Jenkins is an open-source system based on Java. It provides automation of software development process parts without involving people and the process of continuous software integration. Jenkins is widely used in companies where there is a need for automatic applications deployment. The system is free, runs on Windows, macOS and other Unix-like operating systems, as well as has integration with Docker and Kubernetes. Jenkins does not contain a repository with source code, but connects to existing ones via web hooks. Thus is a universal tool for CI/CD regardless of the chosen hosting of remote repositories.

Jenkins benefits:

QOps can work effectively with all the above services.

GitHub and GitLab include the ability to install runners that will later execute commands from a .yml file included in the source code repository when a certain event is reached. Usually such an event is sending source codes (push) or merging branches (merge) in a remote repository. At the same time, the syntax for compiling .yml files is slightly different, although it describes the same essence of runner behavior and managing the process of application building, testing and subsequent deployment. Both hosting systems allow to install their runners in a Windows environment that is not yet available for BitBucket hosting.

Below is QOps usage with the above systems. For GitHub, a .yml file is a structured steps set that consists of successive steps. The example below describes 3 steps – init-build-reload.

Successfully executes pipeline looks like this.

For GitLab, the .yml file is the same structured steps set, the differences are a different name for the keywords and more flexible work with variables. Unfortunately, developers don’t use a unified .yml file format and there is no interoperability between them.

Upon successful completion, a pipeline view consisting of the same stages is presented below. It is worth noting here that GitLab has more developed interactivity. For example, in the pipeline, it’s possible to set up manual confirmation from the user.

QOps currently works exclusively in the Windows environment. If BitBucket is chosen for source code hosting, the automatic pipeline can be developed using the Windows version of Jenkins. The versatility of the latter and plugins variety allows to link any remote repository through web hooks. The pipeline structure is written as a JSON object, if configured through the interface of Jenkins itself. And for our example it contains all the same 3 stages – Configuration-Build-Reload.

The result of successful pipeline execution in Jenkins is shown below. At the same time, the interface compares the results of previous launches in an interesting way.

More information you can find at the link

Branching strategy for large Qlik projects

Speed and flexibility of software development play an important role. However, with a large development team working at the same time, branching and merging code can get messy. These teams need to be provided with a process to implement changes concurrently. An effective branching strategy is a priority in resolving this issue.

A branching strategy is a set of rules that developers follow when writing, merging, and deploying code when using version control. In situations where multiple developers are working and adding changes at the same time, the branching strategy structures the repository and avoids merge confusion. Merge conflicts hinder rapid code delivery and hinder the creation and maintenance of an effective DevOps process.

Thus, the branching strategy creates a clear process for making changes to the system. This helps to solve this problem and provides the ability for multiple developers to work in parallel and independently to release faster and minimize conflicts.

The branching strategy allows to:

The branching strategy is an important working tool. Arbitrarily creating branches in Git by different developers can lead to chaos. A branching strategy will allow to redirect attention to the development process itself, rather than version control.

Branches in Git are represented by tags or pointers. All changes are tracked as a directed acyclic graph, each node of which is a set of changes made simultaneously. Git branches provide developers with the ability to deviate from the master branch and create separate branches to isolate code changes. The default branch in Git is «main branch». The main advantage of a Git branch is its «light weight». That is, the data consists of snapshots series, and each time Git commits changes. It takes a snapshot of the current files state and keeps a link to this one. Such branches are not just copies, but also a pointer to the latest commit.

Basic Git branching strategies:

An example of a merge conflict and its resolution

Let’s look at an example of a merge conflict and possible ways to resolve it using QOps to control versions of a Qlik Sense application. Let’s take a Qlik Sense application and use QOps to create a source code repository and 2 branches dev1 and dev2 for individual developers. Imagine a situation where each of the developers changed some common element (for example, the background objects color with the output of KPI values).

Since the changes occurred on the same lines at the source level, when merging dev1 -> master and dev2 -> master, a merge conflict occurs in the last variant. Resolving a merge conflict requires deciding which of the options should be present in the reduced version. The VSCode development tool allows to interactively make this decision. However, this puts additional responsibility on the IT specialist who will perform the merging.

There is a risk of receiving from both developers code parts for a common element in a final application that may not be compatible. For example, after a merge, it is possible to get the following result when the first object is set to Accept Incoming and the second is set to Accept Current.

It is convenient to merge source codes using the web interface of version control systems. Below is the progress of a Pull Request on GitHub with a conflict-free merge.

The presence of conflicting changes leads to the output of the corresponding warning and additional information.

GitHub interface allows to resolve merge conflicts in small files, while the user needs to manually edit the source code marked as conflicting and confirm the changes. If this operation can’t be performed through the web interface, GitHub will ask to resolve conflicts locally.

Also, let’s resolve the existing conflict in the opposite way. As a result, we get the expected result with the opposite coloring of common elements.

Detailed QOps information here

Benefits of using CI/CD in Qlik application development

Continuous integration (CI – Continuous Integration) and continuous delivery (CD – Continuous Delivery) are one of the typical DevOps practices that allow developers to deploy software changes reliably and quickly. The key difference from manual development lies precisely in the automation of testing and code assembly.

For a long time, due to tools lack in the Qlik ecosystem for fully extracting application source code and its corresponding automatic assembly from source codes, the practice of CI / CD approach implementation was not available for developing and effectively managing projects based on Qlik technologies.

For Qlik developers QOps utility provides opportunities that were previously available to all other developers using a git repository for storing source codes and configured runners for automated tests and deployment.

Let’s take a look at the main aspects of the concept of CI / CD as a DevOps practice

Continuous Integration. Developer regularly makes changes in the applications development process. And these changes are uploaded to the repository. Automated testing and verification are provided through special tools such as events, that initiate the integration as a process consisting of stages and steps set. The execution of each step is accompanied by logging, that reflects all changes.

Continuous delivery automates deployment in any environment (production, test environment, development environment). Automated testing and deployment process provide developer with opportunity to focus on improving the software.

The advantage of CI/CD is to reduce the time spent on developing a software product, minimizing and identifying errors and defects in the early stages of code creation, reducing the time to correct errors, and reducing feedback cycles.

For example, there is a site that displays sales analytics for a certain company. The architecture of this solution includes a backend (can be represented by a database with a specific ETL process for data processing) and a frontend (in the case of using Qlik technology, the frontend is provided by an installed web server). During development and updates, individual developers make changes to one or both parts. Then changes are merged into the repository at the source code level, go through the entire pipeline and, ultimately, the changes are reflected immediately in the entire product.

CI/CD cycle stages:

  1. Creation (writing a certain part of the code and subsequent testing; after successful testing, code parts are combined into one whole and transferred to the working development branch);
  2. Assembly (version control implementation using Git, automatic assembly taking into account changes and received code testing);
  3. Testing (code verification implementation by a team of testers);
  4. Release (code transfer to release, creation of a working build to update the current version of the product);
  5. Deployment (broadcasting the update on the developers’ servers to update the software to the latest version);
  6. Support (monitoring user reviews);
  7. Planning (creating a list of changes for future versions).

Using QOps in the Development Life Cycle of a Qlik Application

Automation of integration and deployment processes is performed by the installed GitHub/GitLab runner, that is integrated with a repository. Bitbucket automation tools can also integrate with the Jira tracking system. It simplifies the task management process, makes it possible to see in which repository branch the desired update is located and follow its further progress. To receive commands from a runner, QOps must be installed on the same server as the runner. This makes it possible to include QOps teams in the integration and deployment pipeline of Qlik applications.

Benefits of using QOps

An example of using QOps in the integration and deployment pipeline of a complex Qlik application

The following pipeline is integrated to automate the processes of supporting and updating complex Qlik application of one of company’s clients using GitHub Actions.

Qlik application has a 4-layer structure (transformers – model – dashboard – extractors) and is made in QlikView architecture.

The pipeline is built in such a way that the stages of its execution are determined by the name of Git repository branch. All changes are tracked there.

Below are the active steps that will be executed if a branch named UAT-* is used. The task of this approach is to prepare the necessary files in a separate folder for the trial deployment of a new task when creating a new branch.

After confirming task completion current development is merged with the main repository branch and execution of all process stages is initialized. At the same time, the pipeline uses the logic of selecting only those application files that have been changed. These files are transferred to a given environment, for example, to production.

Development process of the pipeline greatly simplifies runner functionality in the form of using matrix operations on a list of same type applications. This approach is convenient to process transformers that have a similar structure and purpose.

This is how the result of executing successive pipeline steps within one stage looks like. Some steps depending on the conditions set can also be skipped, ignored, or stopped if errors are found.

In case of a runtime error, the pipeline will signal it as follows.

For a more detailed study of each execution step, console output is available at each stage. This makes it convenient to track and resolve errors that occur.

So, CI/CD introduction into Qlik application development and maintenance process has reduced the time spent on converging the results of parallel development and greatly simplified the process of preparing application files for further deployment.

More information about QOps at the link

QOps: key benefits of using

Qlik is one of the leading BI system providers. Its main products are QlikView and Qlik Sense (data analysis and visualization tools that provide the ability to access and explore data from different sources). Qlik users can independently develop visualization objects (reports, data models, analytical programs, etc.) without IT specialists participation. Qlik solutions are relevant for different use cases, for example:

However, all this is preceded by an extensive process of Qlik application development with individual needs and business requests. QOps console tool developed by DataLabs is designed to solve a number of tasks in the development, version control and subsequent deployment of Qlik applications.

Development

The main QOps advantage for developers is the ability to use previously developed components in one project and implement them in another. Developers often work on several projects in parallel, and the need to transfer ready-made features from one project to another is relevant. The traditional approach involves some complexity, steps and time costs to implement the transfer. So, developer needs to go to the previous project that may be on a different server, find the appropriate reference points where there may be changes (in the script, charts, variables, etc.). QOps allows to solve this problem very quickly. Using this tool, it becomes possible to save a component developed in one project as a separate commit and, by selecting it directly in the repository, see all the necessary changes. And then it is possible to transfer it to the required project. That is, QOps is an auxiliary tool that allows to extract source codes from Qlik applications.

Also, QOps allows to reduce the routine manual work of developers during deployment and troubleshooting. For example, several developers work on one application, and each of them develops its own part. Then, to create one whole project, developers need to agree on how changes will be made from each developer. Another problem is that 2 separate finished parts may not work together. QOps automates this process with GitLab, GitHub, or Bitbucket repositories where it merges, checks for conflicts, and resolves if necessary. Thus, developer doesn’t need to keep all the changes in his mind to implement a certain task or functionality. It is important to note that a developer is an ordinary person who sometimes makes mistakes. Any manual process, in particular deployment, increases the risk of making mistakes. QOps for its part helps prevent this from happening.

Another benefit of QOps is the ability to move a project from one environment to another. Today a lot of organizations are moving to the cloud that allows users to work from anywhere. However, there are companies that require developer to work from a specific isolated device. QOps allows to extract source code from one environment and work in another. There is a question of compliance with safety requirements. Since QOps only extracts a source code and not the data itself, there is no security breach.

Deployment

Using QOps, it’s possible to simplify deployment process and even deploy applications without detailed knowledge of its development specifics. This can be done by a team leader, or a project manager, or a DevOps. User can also use placeholders in the source code that will be automatically substituted when migrating source codes between environments or clients. This ensures correct automatic deployment without any unusual moments or manual changes. So, this reduces time spent on deployment and opens up the possibility of finding new ideas and/or creating a new product.

Version Control

The main task of the version control system is to record changes in a file or a set of files in a certain period. This allows users to return to a previously defined version at any time, return selected files or the entire project to a previous state, track changes and its author, and correct errors if necessary. The version control system allows to divide the source code into branches (separate parts of product development). During the development process they can merge (Development →Master), separate into a separate product that provides complete freedom of action for each developer and each version. It is important to note that a control is based on specific version and only commits changes, not the entire version. QOps allows to get code from developed Qlik applications, put it in a repository in any branch, accumulate changes and explore them (track changes, errors, author of changes, etc.). QOps is an intermediate tool between Qlik and modern Git-based version control systems.

The QOps installation procedure is quite simple, however, it involves some requirements:

An example of merge of collaborative Qlik Sense app development

Let’s create a new app in Qlik Sense. As a data model we use a synthetic set of values specified in a table form using the INLINE operator.

We’ll create a draft of the future sheet design in visualization part

Let’s save the application and use QOps to check out a new application source code and place it in a GIT repository in the master branch. We’ll divide the further application development into 2 developers. They correspond to branches dev1 and dev2.

The first developer is working on the left side of the sheet where he designed the bar chart and the table below it.

At the same time the second developer is designing the right side of the sheet, where the data is visualized using a donut pie chart and a scatter plot.

After the work was completed, each of the developers made the appropriate commits to their branches. Let’s merge the main branch of the repository with dev1 and dev2 alternately. Below you can see this process in the Visual Studio Code development environment. Due to the use of a draft from the planned visual components, there are no conflicts, and the merge is performed automatically.

Below is fully designed application sheet after merging and subsequent assembly with results of both developers work.

More information about QOps here

QOps work principles

The main problem that QOps solves is the difficulty of applying the GIT version control system to the final development file, that contains data, data model, data loading code, codes of all charts and objects for visualization.

What is GIT?

GIT is a version control system that helps track changes made to a codebase, identify the user who made them, and recover deleted or modified code. GIT is one of the most popular open-source version control systems at the moment and is very easy to use. GIT is also completely free software and supports different operating systems (Vac, Windows, Linux, Solaris).

The benefits of GIT are:

How to use GIT in the development of Qlik applications?

The problems of applications parallel development and tracking changes in the source code, development process involving more than 1 developer, manual deletion of code and charts are solved by GitLab and GitHub. However, if you put the Qlik Sense/QlikView file on GitLab, this will not work. This file must be divided into separate parts: code, chart settings, variables, extensions etc. Then these parts should be put back into a file. QOps helps automate the process of application disassembling and reassembling.

How does QOps work?

QOps extracts absolutely all source codes from the files of developed applications. Thus, the extracted codes can be placed in the repositories of any version control systems. Modern version control systems have advanced tools for branches, commits, and merges. This allows multiple developers to work on a project in parallel.

QOps allows to automatically build an application from a local or remote repository. Source codes are stored separately from data, that provides flexibility in the development of complex projects. This makes it possible to set up automatic testing and deployment of the application. This, in turn, allows to avoid accidental errors during deploying applications to production, as well as reverting to any previous version of the application, if necessary.

QOps allows to:

More information about QOps here

GoUp Chat