The Qlik ecosystem is at an inflection point. AI systems and automated pipelines are starting to consume analytics output as input, not just present it to a human on a screen. Teams that managed fine with manual deployments for years are finding that the reliability bar has quietly moved. A dashboard that a person glances at once a week is one thing. A Qlik data model that feeds a downstream system every hour is another.
Most teams have never mapped out how they actually deploy. They just do what they have always done. This is a model for naming that. Five levels, from manual export to infrastructure-grade. It is not a scorecard to feel bad about. It is a map, so you can see where you are and what the next step actually looks like in practice.
This is the default, because Qlik does not provide version control out of the box.
What it looks like: someone exports a QVF from the QMC, renames it, and imports it into the target server. The current version of an app lives on whoever’s machine touched it last. “Who has the latest version of the Sales app?” is a recurring Slack question. A rollback means hoping someone saved a copy before the change. There is no history of what changed, when, or why.
How you got here: nobody decided this. It is what happens when a BI tool ships without a deployment story and the team is small enough to get away with it.
When it breaks: someone publishes over a colleague’s work and a morning of effort disappears. Production breaks on a Friday afternoon and there is no clean way to roll back. An auditor asks who changed a given expression and when, and the honest answer is that nobody knows.
Typical team: one or two developers, a handful of apps, low deployment frequency. At this size the chaos is survivable, which is exactly why it persists.
The team has felt enough pain to add process, but the process is still human-run.
What it looks like: naming conventions like app-name_20260603_v2. A deployment checklist or a runbook in a wiki. Manual backups taken before each publish. A change log kept in a spreadsheet.
What improved: there is at least a process, and backups exist somewhere. A new developer can be pointed at the runbook instead of a person.
What still breaks: naming conventions drift the moment two people are under deadline pressure, and you end up with three files all claiming to be “latest”. The checklist gets skipped when someone is in a hurry. There is still no way to compare two versions of an app. You can restore a backup, but you cannot see what was different between yesterday’s working app and today’s broken one.
Typical team: three to five developers, a growing app portfolio, and the first real coordination pain. This is usually where someone starts asking whether there is a better way.
This is the jump that changes everything, and it is also the hardest one to make.
What it looks like: the Qlik app is decomposed into human-readable files, typically YAML or JSON. One file per measure, dimension, sheet, variable, and connection. Those files live in Git: GitHub, GitLab, or Bitbucket. Developers work on branches and merge through pull requests. For the first time, a diff is possible. You can see exactly which expression changed, in which measure, and what it was before.
Here is what a change to a measure looks like once an app is decomposed:
# measures/revenue-per-customer.yaml
qDef: |-
- Sum(Sales)
+ Sum(Sales) / Count(DISTINCT Customer)
qMetaDef:
title: Revenue per CustomerThat two-line diff is the whole point. Before source control, that change was invisible inside a binary file. After, it is a reviewable line in a pull request that a colleague can question before it ships.
What changed: “what changed?” becomes an answerable question. Code review becomes possible, because a reviewer sees the diff instead of a binary blob. Branching means two people can work on the same app without overwriting each other. The Git history becomes an audit trail that writes itself.
The honest part: most Qlik developers have never used Git. The decompose-and-compose step has to be set up and trusted. The training is a real investment, not an afternoon. But every level above this one is built on source control, so the payback compounds.
Typical team: five to ten developers, multiple environments, and deployment pain that is now visible to management.
Source control answers “what changed?”. A pipeline answers “deploy it the same way every time.”
What it looks like: a CI/CD pipeline (Jenkins, GitHub Actions, Azure DevOps) watches the Git repository. A merge to the main branch triggers an automated path: deploy to DEV, run validation, promote to TEST, run smoke tests, wait for an approval, then deploy to PROD. Validation gates check expression syntax and naming conventions. Smoke tests confirm the app opens and the data loads.
A reference flow looks like this:
Developer commits -> CI validates syntax -> Code review
-> Merge to main -> Deploy to TEST -> Smoke test
-> Approval gate -> Deploy to PROD -> VerifyWhat changed: deployments are consistent and repeatable, because a machine does them the same way every time. Nobody deploys from the QMC by hand anymore. A rollback is one Git command: revert the commit and let the pipeline redeploy the previous version. Senior developers stop being the human deployment service and get their time back.
Typical team: five to fifteen developers, often in a regulated industry, or any team that has systems downstream of Qlik that cannot tolerate silent changes.
At this level Qlik is treated like any other production system in the enterprise, not as a special case that lives by its own rules.
What it looks like: a full audit trail where every change is tied to who made it, when, and why, through commit messages and pull request history. Compliance reporting that can generate a change report for an auditor without a scramble. One pipeline that manages Qlik Sense, Qlik Cloud, and QlikView together. Qlik is integrated into the broader engineering process rather than sitting beside it.
What changed: the Qlik team operates at the same maturity as the application engineering team. “What changed?” is answerable for a regulator, not just for a colleague. A new developer onboards into a documented, structured workflow instead of inheriting tribal knowledge. The single-senior-developer bottleneck is gone, because the process does not depend on one person’s memory.
Typical team: enterprises with ten or more developers, regulated data, and AI or automated workloads consuming analytics output. This is where the reliability bar I mentioned at the start actually bites.
A quick self-assessment:
If you are at Level 0 or 1, the highest-value move is not a pipeline. It is getting to Level 2, source control. Everything else is built on it, and trying to automate a process you cannot diff is putting the roof on before the walls.
If you are at Level 2, you already have the hard part done. Adding a pipeline (Level 3) removes the remaining manual deployment work and is a much smaller behavioral change than learning Git was.
If you are at Level 3 or 4, you are ahead of most Qlik teams. The work now is expanding coverage to more apps and training more people, not new tooling.
The jump from Level 1 to Level 2 is the hardest, because it asks for the most behavioral change: learning Git, trusting a decompose step, reviewing diffs instead of files. It is also the highest-value jump, because every level after it depends on it. If you only make one move this year, make that one.
None of this is primarily a technology problem. The tooling to decompose Qlik apps, diff them, and run them through a pipeline exists today, and the patterns (Git, pull requests, CI/CD) are proven across the rest of software. The hard part is organizational: training developers who have never branched a repository, and shifting a team from “publish and hope” to “review and merge.” That takes weeks, not days, and it is worth being honest about that before you start.
If your team is at Level 0 or 1 and you want to see what the jump to Level 2 and 3 looks like on your own apps, we put together a 15-minute walkthrough that shows the decompose, diff, and pipeline steps in practice. No slides. Book a walkthrough.
No comments yet.
Leave a comment