How to best manage deployment between TEST and PRODUCTION instances?

#1

Hello,




After an initial proof-of-concept trial of various Dashboard software we decided upon Dundas since we found it could do what we needed to do (replacing Oracle Reports primarily, but communicating with our other databases was important as well).



I’ve been in contact with Support about several issues with configuration and overall understanding what I can and cannot do within the software and I’m (very, very slowly) working my way through the details of how to implement for one reports/dashboard. I’ve also taken the 300 and 400 level trainings offered, although I didn’t take 100/200 (yet) due to a scheduling conflict.




I’m trying to determine the best infrastructure for creating reports and dashboards and then deploying them. I’ve got a TEST project and a PRODUCTION project (that each point to different databases) on the same server. Right now it’s mostly me working on reports, but I’ve got multiple developers that will need to be able to build and then deploy reports. What I’m finding is that when I build something, e.g. a cube and a metric set and a dashboard, and then deploy (publish) that to production, EVERYTHING goes along with that publish, including stuff that might not be ready.

I’m also getting copies of everything from TEST if the same thing already exists in PRODUCTION, including the time dimensions. This seems very messy and hard to manage.



There has to be a better way to deploy from one environment to another and I would hope there would be a way to do pieces and parts individually. Can anyone help me out with understanding how I might achieve this?





I'm coming from the database developer/programmer perspective.

Joyce Young

#2

Hi Joyce,


Based on your reference to publishing, my understanding is you’re working with two different projects within a same instance of Dundas BI.


When publishing items from one project to another project, Dundas BI gives you the ability to publish the entire project or selective content. You can either right click on the project name to access the public feature or right click on an entity e.g.: a metric set or data cube to access them individually as well.


Publishing by selective content would be the best approach in your use case as not every item within your test project might be ready to be moved to a production project.


Another thing to keep in mind when publishing content between projects is, if you select Publish referenced items from the options on the publish window, then it’s quite possible that items that are not ready (such as other data cubes or metric sets) might get moved along as well. If this is the case, you might want to uncheck this box. However, it is highly recommended that you do leave this checked, otherwise a dashboard or KPI from the production environment might be referencing something in the test environment.


When you are publishing an item to another project for the first time, the item is copied with the same name. If a file with the same name already exists, the published file will get a name with the suffix 1, or will increment by one if the name ends in a number. Publishing creates a relationship between the source and published files. When you publish the same file to the same project more than once, the previously published file will be overwritten by the new version.


For more information on working with projects, please give this article a try: https://www.dundas.com/Support/secondary/working-with-projects


Regards,

Ash

1 Like
#3

Hi Ash,

Thanks so much. Somehow I missed that individual items could be published. This helps with the potential overwriting and multiple copies, I think.

What is the best way to manage datacubes and metric sets between environments? It looks like I can put them into the GLOBAL project once I get them the right way and as long as I have dataconnectors that point to the correct databases in each project (TEST vs PROD) the dashboards that use those two things will work regardless where the dashboard exists, correct?

I can't seem to push dashboards to the GLOBAL project though so it seems I just have to move my dashboards between wherever they were created and whatever project they are ready to be put in. Correct or is this way off base?

Lastly it looks like Notifications are not project-based? I created one in my TEST on a dashboard but now I have two and I cannot tell which is which so I’m wondering what’s the best way to manage that?

#4

Hi Joyce,


The best practices regarding managing data cubes and metric sets between environments assuming there is 1 project for Testing/Development and 1 project for Production are as follows:

  • Create data connectors, data cubes, and metric sets in the Development project.
  • Once the content is ready to be shared in production, publish it into the Production project.

Note: If you use different databases for the two projects, update the data connector after publishing to the Production project.

  • When changes are required in a data cube or metric set, make theme in the Development project.
  • Once the changes have been made, publish the updated items into the Production project. Dundas BI will overwrite the old items in the Production project with the updated ones.


Note: If this is not the first time you are publishing to the Production project and you enable “Publish Referenced Items”, then you might have to update the data connector in the Production project as it may have been repointed to a different database, depending on whether you have separate databases for the two projects.


If you have dashboards that rely on data cubes or metric sets that are located in different projects, they should function properly as long as the referential integrity is maintained. To make sure the references are linked up properly, you can pull up the reference tree. For information on the reference tree, please see the following article: https://www.dundas.com/support/learning/documentation/get-started/file-and-folder-properties under the section “References to and from the file.”


Aside from the two projects mentioned above, you also have the GLOBAL project where content that is meant to be shared across all projects would be located. As a user, with the right permissions, you should be able to publish content to a GLOBAL project.


Notifications are not project based; however, they are tied to a user profile. A user can manage their notifications via the profile menu. For more information on managing notification, please see the following article: http://www.dundas.com/Support/learning/documentation/design-view/notifications-alerts under the section “View or update notifications”


Hope this helps.

#5

HI Ash,


Again, thanks! I'm getting closer to understanding and also developing the process to show the other developers.....

However I'm running into an error when I try to publish a dashboard only (the data cube and metric set are already on the destination). The Dashboard is checked in on TEST and ready to go to PROD with no changes to the data cube or the metric set. I do have "Ignore Warnings" on, but I don't have the "Published Referenced Items" marked, but I'm getting this message:


Error 1 of 1

Title: The item you were trying to publish failed. Below are the names, IDs and status of the items.

Details: Error - '[CIS - TEST] Metric Sets Root Folder/Form 8300 Report Table' (afbe2256-bec0-4e89-b981-27f19e5f17ec): All items are required to be checked in before they are published. This item is checked out.

#6

Hi Joyce,

If the items are checked in and you are still getting this error, some more information will be needed to resolve this. I opened a ticket with our support team and someone will contact you directly.

#7

Thanks Elia.

#8

Aside from working within 1 instance and using the publish option between 2 separate project, you can also consider working with 2 instances (1 for dev and 1 prod) and use the built in import/export to move objects between the instances. While it is slightly more work to maintain 2 separate instances (note it doersn't incur additional licenses cost for the dev insatnce) , you do get a more secured / robust development setup where you avoid potential confusion of users "accidently" developing/making changes on the wrong project. You can read more about the import/export option under this article Note the process of migrating work from one instance to another can also be automated via command lines or the API.