So, the answer is ‘yes’. If you want to know more, keep reading. First start by making sure you back up your databases unless you are on the cloud. This is important. The cost of not backing up your development instance would be losing all the project work to date. While good consultants will make occasional extracts, I would not take that risk.
If you have a system and do not have separate environment, you are just about asking for a crisis. Every mission critical application, which OneStream is, needs to have some controlled environment to manage changes that need to be made to the system. You need to test changes before you make them. Change control is the formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. A good process makes you think what changes you want to make, and how you can ensure they are done right.
OneStream should not just have multiple applications, but it should always have multiple environments. At a minimum, there should be two; a development/test and production environment. Each should have their own separate hardware. If possible, you should break the development and test into two, so there would be three (3) environments (development, test and production) with the test and production having identical hardware and software configurations. Any patches for any software could be tested thoroughly in the test environment before it is applied to production. Change control manages the migration of changes from one of these environments to another.
Again, all of this is important unless you are in the cloud. When you are in the cloud you have many servers supporting you. One box failing will not even be something you notice. In more sophisticated environments you might want to consider multiple instances though. And while you might want similar hardware for a physical install, you can have a scaled back develop/testing instance in the cloud with much less risk.
This is a GREAT reason to consider being in the cloud. When people are working through the costs, are they really considering what additional hardware they will need to support the two environments? Or if they think, ‘Well, I’ll have a big one and a simple small one…’ That might be ok, if you accept it is completely possible in a physical installation a single software change could pass the small environment and cause a failure in the larger one. That could be cause of configuration, or just data volumes. For extra cost, being in cloud reduces this risk.
One question everyone asks is, ‘what are things we should test, and what are the things we should let users do directly?’ I answer that, by making the distinction of what application changes could make the system not functional for the whole set of users as opposed to the getting an error on the specific tasks. In other words, if I get an error writing a bad report, then only I will get an error when I try to use that report. If I write a bad rule, I can prevent all users from running any calculation or consolidation. Both could be bad, but a bad rule.
Thank you for the article and for the promotion of safe development practices.
As someone just becoming a OneStream administrator, please let me ask some questions to better understand. And tell me if these questions don't even make sense for OneStream.
I'm used to working with systems in a Dev / Test / Production setup for larger system changes. But I've also been involved with PowerBI and Access and Excel where it's easy to make an update to a report, test it, make a backup of what I'm about to change in Production, copy the new item to Production, and return to the backup report if someone discovers a problem in production.
Hi @chuckbo !
First a reminder : You can use the Object Usage Viewer that can help you find and highlights the impact of a change to an object in the application. It is implemented for :
All dashboard objects.
Then regarding the migration itself... The process should be rigourous. But first, you need to know if you are migrating within the same server if you host it yourself as the security could be different on the DEV vs PROD. That would have an impact on your security groups for your objects... but lets not overcomplicate and lets assume you are on the same server.
First, I would start my DEV being a perfect clone of the PROD. That means that DEV is an sql backup of PROD.
Second, I would have previously made an excel list of all object that were changed. From this list I would export them in XML.
Third, I would recommend to have another TEST environment being also a clone of PROD to test the migration.
Fourth, if the migration XML are migrating to TEST without issue, you can load the XML to PROD.
If you want to compare the XML between PROD and DEV, Onestream as a tool for that too!
@NicolasArgente , If you want to compare the XML between PROD and DEV, Onestream as a tool for that too.. which tool is this please?
@NidhiMangtani It is called "Dimension Comparison Utility" and is available on the marketplace. Please read the doc as it has some limitations
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.