Collaborative Work in Qlik with Gitoqlok

Developers’ urge to work collaboratively has fallen short of the native version control system in Qlik Sense. Gitoqlok has been meeting this demand, yielding a seamless integration of Qlik and Git in the form of a browser extension.

Systematic customer support sessions across Gitoqlok users established a success story forming a holistic approach to developing an effective workflow in teams.

Before getting into the valse of Pull Requests and Merges, let’s set the records straight on the basics of Git notions:

• Git is a version-control system for tracking changes in files and coordinating work on those files among multiple people;
• Commit represents a snapshot of changes made to files (e.g., code) at a specific point in time. Each commit contains information about what was changed and by whom. In aggregate, commits constitute a version history;
• Git repository is a central storage for managing and tracking changes in files;
• A branch is an independent line of development inside a git repository. Each developer works in their isolated branch to avoid conflicts when making changes.

Every collaborative project starts with a repository when in turn, the repository automatically originates a master branch, where the first and foremost line of development starts. Typically, the master branch belongs to the senior developer/ team lead responsible for approving their colleagues’ work. The state of the master branch can be further altered with new changes or reverted to an older version of itself.

Developing a Qlik application on-demand is the case when aligned with the business user requirements a brand new Qlik app is created. Let’s set up the background:

Step 1: Sarah creates a repository for a Qlik app called “Customer Sales” on a corporate BitBucket server. She’s working on a master application and developing a data model along with the data load script for further use. Sarah commits her first changes to an app into the master branch — the one she implicitly originated.

Step 2: Sarah is ready to pass the app to her colleagues, Jane and Jacob, so she publishes “Customer Sales” to the development stream in Qlik Sense.

Step 3: Jane and Jacob are responsible for the data visualization part. Both see “Customer Sales” in a stream and duplicate the application. Now Jane and Jacob each have their copy of the master application in their workspaces.

Step 4: Jane opens her copy and branches out from Sarah’s master branch. By that, she just created her isolated line of development which belongs to the application repository. Once Jane creates sheets and saves her changes (i.e., makes commits), those changes are not recorded in the application’s master branch, but instead in Jane’s separate one.

Step 5: Jacob figures out he needs to configure an additional data connection, so he makes changes to the data load script within his branch. Next, Jacob works on the visualization part and continues to make his commits.

Step 4 and Step 5 can be done simultaneously, i.e. developers can work collaboratively with no limitations to a specific timing.

Both Jane and Jacob, while making changes to their sheets, might deploy the visual versioning tools by Gitoqlok (Time Machine and Diff Viewer) to review the changes they made interactively and merge different versions of their sheets. For example, one might add the line chart from version 1 to the version 2, where it was deleted. Respective actions may be done for load script, where the diff viewer highlights the changes line by line.

Step 6: Jane and Jacob have finished their work and both are now ready to merge their branches into the master one. Junior developers proceed to their application Git repository and create Pull requests to consequently merge the changes. Jane is the first one to create a Pull request.

• Pull request allows users to propose merging changes from one branch into another.
• Merge is the action of merging after the approval.

Pull requests may be done either through the console terminal, IDE-bundled GUI tools, or simply through the Git server.

Step 7: As the repository owner, Sarah can see Jane and Jacob’s pull requests, review the changes they made and accept their work. She merges the changes so Jane and Jacob’s commits now become a part of the master branch.

One thing that could act as a bottleneck on a way to merge changes is a merge conflict. Conflicts can occur if both developers modify the same object (for example, they might be working on the same sheet or the same master object). To avoid conflicts, developers should work on different application objects.

Gitoqlok has several options to avoid conflicts, which include:

1) Using original Qlik Application ID in thumbnail URLs when committing to the branch - helps to use correct thumbnails URLs after merging from branch;

2) Not committing full loadScript.qvd file (full joined script) every commit - helps to avoid conflicts when developers are working on a script simultaneously;

3) Not committing Load Script Section order - helps to avoid conflicts when developers are working on a script simultaneously.

Step 8: Once the merge is done, Sarah in her “Customer Sales” app sees the Gitoqlok notifying her of the updates to the application repository. She updates the app to the latest state of its repository.

If you see the Gitoqlok icon with a notification on it, it means you have an out-of-date version of the application. Don’t forget to update your current state.

Customer communication sessions revealed that it is the case across companies to have a single template app that is being reused on a case-by-case basis (i.e. to have a ready-to-use app with sheets and sample data for tailoring them to the business user requirements specifically).

Let’s set up the background:

Step 1: Mike creates a repository for a Template app thus automatically originating a master branch. Since Mike is a Manager, he monitors all the projects streaming from a Template App. Template app is located on the templates’ Qlik server.

Step 2: Sam is responsible for the client Project 1. Sam duplicates the Template App, renames his copy to “Project 1” and makes it visible to Jackson and Jim. Next, Sam branches out from Mike’s master branch. By that, Sam not only created his isolated line of development but also started a separate project to not deliberately alter the Template App which might be used (copied) by other teams.

Step 3: Sam uses the Environment Migration tool to move his “Project 1” app to the development server.

The Environment Migration tool is widely used to migrate Qlik applications and other objects between different Qlik servers. Users are able to import (export) Qlik objects from (to) the Git repository or files saved locally on their device.

Step 4: Next, Sam creates a data model for Project 1 and commits his changes to his branch.

Step 5: Jackson and Jim are responsible for the issues related to the current project. Both of them, upon seeing Project 1 migrated by Sam to the development server, copy the app. In line with the client requirements, they need to work on different sheets of Project 1, thus, they both branch out from Sam’s branch from their application copies.

In case the user duplicates a copy of the master application and the first copy is already branched out from a master branch, Gitoqlok asks from which branch exactly does the user want to branch out further from.

Step 6: Once Jackson and Jim are done with their work, they create Pull requests for Mike to approve their work and merge their changes into the Project 1 master branch.

Mike is the one to merge because he is the owner of the repository. If the merge needs to be done by someone other than the repository owner, rights settings can be easily changed in your Git server. In this case, the rights can be passed to Sam.

Step 7: As the Project 1 initial branch owner, Mike can see Jackson and Jim’s pull requests, review the changes they made and accept their work. He merges the changes so developers’ commits now become a part of the Project 1 branch.

Step 8: Once the merge is done, Sam in his “Project 1” app sees the Gitoqlok notifying him of the updates to his branch. He updates the app to the latest state of its branch.

If you see the Gitoqlok icon with a notification on it, it means you have an out-of-date version of the application. Don’t forget to update your current state.

Step 9: The app is now ready to be moved to the production server. Here, Sam replicates the Step 3 actions and Project 1 is accessible on the production server for viewers.

This article aimed to dive deeper into the specifics of Git-integrated Qlik Sense workflow. Whether it’s a small team of several Qlik developers or a relatively large one, the ease of the versioning workflow in Qlik Sense that Gitoqlok introduces aids many along their path of version control. While the latter process is integrated into the Qlik Sense environment seamlessly in a way which achieves a minimal distraction from the core development interface, Gitoqlok's functionality extends further to reach out to the causes that make Qlik users utilize third-party environments.

Learn more about Gitoqlok at https://docs.gitoqlok.com/ and let us know if you have any questions.