Dashboard/report change release management ideas
Hi YF community, I'm seeking some suggestions.
We provide multiple clients with a fixed set of dashboards/reports etc to analyse their data.
Typically if a change is required we just action it, however management want to introduce more procedure around change request, approval and release.
Given the nature of Yellowfin draft/publish and that changes can range from very minor formatting to intricately linked dashboards & reports, I am interested to hear from other users that have similar situation with development release processes for Yellowfin reports.
How do/can you technically manage in Yellowfin to develop and implement multiple changes as a release?
The thoughts I had were to:
A) Make changes to reports and leave in draft mode until release date. Then publish all drafts individually at one time.
+simple
-messy
-no rollback
B) Make use of import/export.
+quick to release in single go
+can export existing reports as rollback
-would require a dev enviroment
-we have encountered issues with this function in the past, so don't have 100% faith to override existing reports
Regards, Nick
The same question
Hi Nick,
I know that you said you are interested to hear from other users, and in fact I too would like to hear what other users say on this subject, so if you'll allow me a mixed metaphor, I thought I would hopefully start the ball rolling by being first cab off the rank:
Most large organisations that I've dealt with use process B). And regarding the minus you mentioned about problems with import/export in the past. Yellowfin's import/export functionality was revamped last year, so I'm hoping that when you say "in the past" you mean before the revamp.
Also, we do not recommend importing/exporting across different versions - you may have noticed the following warning when trying as such:
so if you keep the version and build of your dev and prod environments in synch then that should eliminate problems.
One other angle on this topic is that I do remember one client who created a virtual dev environment within their prod environment by appending "_DEV" to the name of their reports, and they seemed quite content with this technique.
Hopefully my above comments will encourage other users to join in this discussion...
regards,
David
Hi Nick,
I know that you said you are interested to hear from other users, and in fact I too would like to hear what other users say on this subject, so if you'll allow me a mixed metaphor, I thought I would hopefully start the ball rolling by being first cab off the rank:
Most large organisations that I've dealt with use process B). And regarding the minus you mentioned about problems with import/export in the past. Yellowfin's import/export functionality was revamped last year, so I'm hoping that when you say "in the past" you mean before the revamp.
Also, we do not recommend importing/exporting across different versions - you may have noticed the following warning when trying as such:
so if you keep the version and build of your dev and prod environments in synch then that should eliminate problems.
One other angle on this topic is that I do remember one client who created a virtual dev environment within their prod environment by appending "_DEV" to the name of their reports, and they seemed quite content with this technique.
Hopefully my above comments will encourage other users to join in this discussion...
regards,
David
Thanks for the feedback Dave. Another thought.... would a 'development' Client Org (not Default) pointing to production data provide a good base for development?
It would obviously share the same YF version so no issues keeping instances in sync, and allow easy access for dev and UAT prior to export and release. Downside I guess is duplication of resources in environment.
Thanks for the feedback Dave. Another thought.... would a 'development' Client Org (not Default) pointing to production data provide a good base for development?
It would obviously share the same YF version so no issues keeping instances in sync, and allow easy access for dev and UAT prior to export and release. Downside I guess is duplication of resources in environment.
actually, now that you mention it, I do remember another client who uses the method you've just described. So there you go, that's now 4 different methods we've come up with! It will certainly be interesting reading if some other users tell of their methods and experiences...
actually, now that you mention it, I do remember another client who uses the method you've just described. So there you go, that's now 4 different methods we've come up with! It will certainly be interesting reading if some other users tell of their methods and experiences...
Hi Dave,
Just revisiting this as we are moving to development and production version of the YF config database. Want to get some thoughts on performing a sync of the config database as a release method?
I have written some notes as to how this may work along with Pro's / Con's / questions.
Regards,
Nick
Hi Dave,
Just revisiting this as we are moving to development and production version of the YF config database. Want to get some thoughts on performing a sync of the config database as a release method?
I have written some notes as to how this may work along with Pro's / Con's / questions.
Regards,
Nick
Hi Nick,
with your 1st New design idea, are you aware that if you are going to use Client Source Substitution then you don't have to export/import content across all client orgs? You can have the all of the views and reports just residing in the Primary Org (no views or reports in the Client Orgs), and of course that will make roll-outs of new content much easier.
Regarding your question about whether it is possible to sync only the Client org parts of the dev and prod DBs - I haven't heard of this being done before, however, I suppose it would be possible, you'd just have to filter out any records where IpOrg = 1. The only thing is, I do remember that there is some functionality that is sytem-wide even though it is configured per IpOrg (it's always 1), therefore if you filtered out those records then your Client Org records wouldn't be complete. Off the top of my head I don't remember which functionality works that way, and it would take it a bit of time to research it.
In summary, if all of your clients are going to have all the same reports then Client Source Substitution (with content only in the Primary Org) is definitely the way to go for simplicity.
regards,
David
Hi Nick,
with your 1st New design idea, are you aware that if you are going to use Client Source Substitution then you don't have to export/import content across all client orgs? You can have the all of the views and reports just residing in the Primary Org (no views or reports in the Client Orgs), and of course that will make roll-outs of new content much easier.
Regarding your question about whether it is possible to sync only the Client org parts of the dev and prod DBs - I haven't heard of this being done before, however, I suppose it would be possible, you'd just have to filter out any records where IpOrg = 1. The only thing is, I do remember that there is some functionality that is sytem-wide even though it is configured per IpOrg (it's always 1), therefore if you filtered out those records then your Client Org records wouldn't be complete. Off the top of my head I don't remember which functionality works that way, and it would take it a bit of time to research it.
In summary, if all of your clients are going to have all the same reports then Client Source Substitution (with content only in the Primary Org) is definitely the way to go for simplicity.
regards,
David
Hi Dave,
Yes the idea behind having all clients under one instance in DEV would be to eliminate the need to import/export content across clients, making it easier to manage common content.
I suspect we will have to do a fair bit of testing to get the DB sync right if structures differ as per design 1. As it is we would need to 'import' a one client org to another instance to create a combined DEV instance, so this would be the first test.
Regards,
Nick
Hi Dave,
Yes the idea behind having all clients under one instance in DEV would be to eliminate the need to import/export content across clients, making it easier to manage common content.
I suspect we will have to do a fair bit of testing to get the DB sync right if structures differ as per design 1. As it is we would need to 'import' a one client org to another instance to create a combined DEV instance, so this would be the first test.
Regards,
Nick
well please let us know how you get on with your testing!
regards,
David
well please let us know how you get on with your testing!
regards,
David
Replies have been locked on this page!