topic Re: How to deploy to production? in Archived Groups

How to deploy to production?

Tue, 22 Jul 2025 17:59:49 GMT

Hi Guys,

I have recently joined QDF and have extracted Admin & Shared container on my local machine.

I have some simple questions regarding best practices

Do I have to extract the Admin and shared container on production too ?
Am I suppose to create a new container for each application?
Once I finish developing an application on my local machine, should I just copy the application (QVW) and paste it on Production? or Do I have to copy the entire container?
If I have to copy the entire container to Production then how to best manage folder structure on on QMC?
How to manage connection string for different environments? (Dev, Test, UAT, Production)

About the current Architecture :

We use QlikView 12 Personal edition and QV12 SMB server
NO QlikView Publisher
NO Test or UAT environment

Developer Develops Application by connecting to the Dev Environment of SQL Database ,
Then a tester tests the application by updating the DB connection string to the Test SQL Database
And Once tested then only we change the Database connection string to Production

We have a QVD generator and a QVD updater (Incremental load from SQL every 30 Minutes)
And all the other applications use those same QVD files from one single folder

How do we best manage the process ?

Your ideas and feedback will be highly appreciated.

Thanks

Re: How to deploy to production?

Magnus_Berg — Tue, 07 Jun 2016 07:33:40 GMT

Hi Lokesh, good questions. Here is a thread that might fit your environment well How to set up DTAP in small environments

Hope that this helps.

Regards

Magnus

Do I have to extract the Admin and shared container on production too ?
No, definitely not Admin. If there are content in shared that you want to use in both environments you need to copy these
Am I supposed to create a new container for each application?
No, you can have many applications in a container. Containers are security boundaries so all apps that uses the same access could be in a single container.
Once I finish developing an application on my local machine, should I just copy the application (QVW) and paste it on Production? or Do I have to copy the entire container?
You can copy just the qvw file into the production container
If I have to copy the entire container to Production then how to best manage folder structure on on QMC?
As you do not have a publisher the application folder in each container becomes a mounted folder inside QVS folders
How to manage connection string for different environments? (Dev, Test, UAT, Production)
There is a special folder to store connectionstrings within each container, 3.Include\3.ConnString with the global variable $(vG.ConnStringPath) use this variable as reference/url to the connection string.

Database Connection String in QlikView

Connection strings are a security credential and should always reside in the architecture Back end, in the data tier. Well protected from unauthorized access. Remember that architecture front-end (QlikView Server and QlikView Web Server) does not have any open ports the back-end, these servers could be in different network zones and security boundaries. When distributing QlikView applications via the Publisher in Back end to the application tier, scripts and connection strings will automatically be removed.

Security considerations

By separating the connection string from the script reusability and higher security will be achieved.
There are two ways to separate and reuse the connection strings:

Include File

Best practice is to keep the connection strings in a separate Include file. This behavior is supported by Deployment Framework. Use the Global Variable vG.ConnStringPath to connect inside your container, example:

// Connection string to Northwind Access data source
$(Must_Include=$(vG.ConnStringPath)\0.example_access_northwind.qvs);

If the connection string is in another container, for example the Shared folders use the Global Variable vG.SharedConnStringPath to connect, example:

// Connection string to Northwind Access data source
$(Must_Include Include=$(vG.SharedConnStringPath)\0.example_access_northwind.qvs);

Recommendation is to use Must_Include so that the Qlik script fails if include script is missing.

QlikView Server without Publisher license

QlikView infrastructure without a Publisher license does not have a Back End. The Source documents are loaded with a simple reload engine that is bundled with QlikView Server. This solution works fine with smaller installations, and in development and test environments. In a production environment QlikTech recommends the Publisher and Back End/ Front End separation.

Setting up Containers in QMC

Without a Publisher there is no Source Document structure in QlikView. Instead the Containers need to be mounted directly in the QlikView Servers User Document structure.

When not using a Publisher file system security on the containers will reflect into AccessPoint and QlikView Server, this is not a good behavior. Therefore it’s important to add two mounted folders for every container:

One mounted folder that points to the Container root, used for document reloading. This mount should have Browsable disable, denying end users access to this container.
Example: Name 0.Administration Path c:\QV-Docs\userdocs_test\0.Administration Browsable disable
One mounted folder pointing to 1.Application inside the same Container. This mount should have Browsable enable, allowing end users access to the application folder.

Example: Name 0.Administration_1.Application Path c:\QV-Docs\userdocs_test\0.Administration\1.Application Browsable enable.

A container that only is used for reloading and not for end user presentation do not need the second mount (to the 1.Application folder) it’s very important that Browsable is disabled.

Do not uncheck the setting Respect browsable flag on mount in QlikView Web Servers settings. This will disable the Browsable functionality in QlikView Server Mount Settings.

QMC task scheduling

Creating a reload task with no publisher is quite straight forward. Remember that without a Publisher license only scheduled reloads is possible.

Start QlikView Management Console (QMC) and click on the Documents Tab. Select the (User Document) container and QlikView Document that needs to be reloaded and add schedule in the right pane.

Re: How to deploy to production?

Tue, 07 Jun 2016 10:19:04 GMT

Thank you Magnus,

Pleas forgive my ignorance but I found QDF little confusing (may be lack of my experience) but anyways, I have created my own custom QDF inspired by the original QDF.

I have simplified my version to be very straight forward and useful for small teams without publishers.

I have also incorporated source control for the entire QDF which helps a lot to version control each and every aspect of the QDF (Include scripts, expressions, variables, load scripts and QVWs)

I have also created custom Octopus Deployment too which will automatically deploy everything from dev to test to UAT to production.

I will be sharing my solution here this weekend and would love to get feedback.

Re: How to deploy to production?

Magnus_Berg — Tue, 07 Jun 2016 11:38:51 GMT

That sounds great Lokesh, the idea with a framework is that you can take the pieces needed for you and leave the rest. Especially as the framework is designed with the Publisher in mind from the beginning.

Regards

Magnus

Re: How to deploy to production?

Tue, 07 Jun 2016 12:27:07 GMT

I agree and I think its great when you are big organisation and have multiple data sources. But i also think its bit too much when you have single data source like in my instance. I will update you when post my version. Thank you for taking time in replying my question.

Re: How to deploy to production?

Wed, 17 Aug 2016 17:36:38 GMT

Hi Lokesh,

Would you be able to share your solution on version control on each aspect of QDF and how the DTAP work for all these?

Thanks!