5 Replies Latest reply: Aug 17, 2016 1:36 PM by zhen ming liew RSS

    How to deploy to production?

    Lokesh Patel

      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

       

      1. Do I have to extract the Admin and shared container on production too ?
      2. Am I suppose to create a new container for each application?
      3. 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?
      4. If I have to copy the entire container to Production then how to best manage folder structure on on QMC?
      5. 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

          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

           

          1. 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
          2. 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.
          3. 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
          4. 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
          5. 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.



          Read more in the:


          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?
              Lokesh Patel

              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

              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