Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I would like to use the QDF also for small solutions to set up a DTAP process. We only have one QV server. Reading all the manuals and examples it is still unclear to me if I should deploy (install) the tool 4 times or just set up 4 containers after deploying the QDF once?
In the first situation, I get four complete folders, that contain a.o. the 0.Administration and 99.Shared containers. In each environment I just set up one container for respective each environment (DTAP)
In the second set up, I just have one 0.Administration and one 99.Shared container and here I'm going to add (set up) four containers (one for Development, one for Test, one for Acceptance and one for Production).
I think that I should use the latest set up (so only deploy the QDF tool once), but I'm not sure.
Can some please help me?
Thanks
Marcel van den Dobbelsteen
I think that I should use the latest set up (so only deploy the QDF tool once), but I'm not sure.
That would be my guess too. And that's also how I read page 6 of the QlikView Deployment Framework-Deployment Guide.pdf (version 1.3) document:
Resources:
Containers
Use different containers for test, sandbox, acc and production.
Imho the DTAP procedure should be applied only to those resources that actually need to go through D, T, A and P stages. So unless you want to put the QDF framework itself through the DTAP procedure, I'd use only one installation of the QDF and containers for the different environments.
Hi Marcel, I agree with Gysbert. In a single server environment different containers can be used for different stages. Using separated QDF deployments is only valid when moving across physical separated environments.
Best regards
Magnus
So, is your directory setup like the following:
How did you run the initial QDF setup to arrange the folders like that? Or did you do it in the Variable Editor? I think it would be great if you could post the steps you took to create this type of structure. Does it break using the variable editor in the Administration folder?
Thanks,
Phil
I used the Button Container Map Editor in the VariableEditor.qwv (in the administration container) to set up the new containers. It's very easy. Just press the Container Map Editor button and you'll see all present containers.
Use the big arrow buttons to insert new input. Press Update Map and create Containers button to see the new inserted lines as oprphans containers in the right upper window and press Create containers to get the folder structure be created under windows.
I know how to use the variable editor to create containers, but since it does not create the sub application containers I am confused. Or maybe I am doing something wrong. Could you post a screenshot of your container setup please. In my mind, I picture your container editor to have 4-5 containers, 00.Admin, 01.DEV, 02.TEST, 03.Prod, 99.Shared.
Hi Phillip, If you want to create sub structures using Variable editor just add the folder name in front of the container name separated using a \, like this:
1.Dev\1.Sales
1.Dev\2.HR
2.test\1.Sales
2.Test\2.HR
3.Production\1.Sales
3.Production\2.HR
This will create three sub folders containing two containers each. Remember that the container Prefix need to be unique, so you have to use prefix name like Sales_Dev Sales_Test Sales_Prod
The good thing using this design is that all the environments can have a common QVD source structur to load the data from. Example:
4.Data\1.SQL_XX_Mart
4.Data\2.MySQL_DBXX
...
Hope that this will help you.
Regards
Magnus
My structure looks like what you wrote:
Marcel,
Can you tell how you deploy the application from Ontwikkel (=Development) to Test and Prod?
Regards,
Frank
Hallo Magnus and all others,
I have to say that I as well have problems in deciding what the right way for moving along the DTAP street is, even if I have started using 99.Shared_Folders and version control, so that I have a lot of folders with suffix "-prj" that are not needed in T, A and P (Test, Accept, Product) environment.(Solution here is using Remove-prj.cmd. Thx for that).
But as known from other development processes (.NET, Java) you have to think about dependencies. If a app just depends on self contained code you will have no problem. But if it starts with includes and QDF code, that is not under your version control, it all gets more complicated. QDF itself is versioned code and if you test your app that uses QDF, you always test it against a specific QDF version.
So think about a scenario where development team has decided to switch to a new version of QDF and i.e. starts using new functions that are shipped with this new QDF version.
So you can not simply move the qvw into the test environment that might run under the older QDF version. You also could not switch the test environment to the new QDF version because this version may function different in some case and your test become worth nothing.
So from my point of view you always should full encapsulate D, T, A and P. So each one of them should have its own Administration and Shared Folders.
Different Versions of own code in 99.Shared_Folders in development and production environment is another argument for full encapsulating the environments.
It's a shame that there is no way to make a "Build" and an installer to manage all this. This would be a really great feature.
So feedback to my opinion would be great and I hope that QDF team again reviews this and might come to a clearer description of the deploy process of QDF along the DTAP street. Might be that there are two streets.
But hey, you have done a great work so far.
Regards
Frank