I have Dynatrace installed on production since 1 year ago on a WEB Application . A year ago, before moving to prod, we have made all the tests on preprod . Now after 1 year, every time we have a new functionality/ enhancement/ release we are required to perform tests in lower envioronments. Does it makes sense ? What are the pros of having another license ?
Hello Sebastian, thanks for your contribution. May be there is information i did not share in my initial question, my bad.
All infra components ( DB, apache servers, app servers ) are Multi Tenant, we are supporting multiple customers with the same application.
My question was more related to understand other implementaions of Dyantrace in lower envioronments. i.e. Imagine you have DT installed in prod and there are new functionalities that will be included in a new release, we do all testing processes of the SW before moving to prod. Then when you are in prod it will be the first time you can see Dynatrace working and monitoring the new functionalities.
Does it makes sense to have another license for preprod? Whithin the model of Dynatrace are there posibilities to have testing licenses only for these purposes and avoid extra investments ?
My recommendation is to monitor application on development, pre prod and prod to build full CI/CD process based on this tool. We are making such implementation on our clients. Such pipeline helps resolve many issues before going to production. Separate license is good idea but you will need to move some extra configurations between environments. Some of them can be handled via configuration API which may be helpful 🙂
It is a very good practice to monitor the production and test environment.
You can implement Continuous monitoring at all stages of the CI / CD delivery pipeline. Thereby minimizing the percentage of bad software that can reach real users
Andi Grabner have several good blogs about it. Examples:
About the license, I advise you to watch on hourly license, it has a limit on the number of hours per year. For a test environment, it can be one of the options - in the test run, you turn it on, after you turn it off
I am not sure about managed, but take caution when it comes to SaaS. We have found that for the most part if you have 2 accounts such as a paid account and a developer for life account, they are separated for the most part.... BUT, if you are using something like the Single sign-on and attempting to test the configuration, it does in fact effect any and all accounts. We learned the hard way. Dynatrace has stated this is by design, however by design or not, the settings area of Dynatrace needs a major overhaul as there are many things that can be misleading. Why that would be by design is beyond me as they have effectively killed the ability to really test Single sign-on. The only way I "think" you might get around it is to just sign up for a 30 day trial and use a Gmail address so it truly is a separate account. But then you run into another problem which they state is by design. You can only verify the same domain 1 time.
Hope that helps!
So here at our organization we are managed. Everything has to be tested in a test/dev/qa environment prior to rolling out to production. We are licensed via host units with unlimited overages. so as long as we ensure that we are under the host unit usage we will not see any overages. A host unit is consumed per 16gb of Ram on a host.
We have 3 different environments within our Managed instance. Production, Test/DEV/Qa and Playground.
Production has all of our Business Critical devices and is tied into our helpdesk as well as OnCall.
Test/Dev/Qa has a handful of test boxes of Business Critical devices as well; so as developers make changes at the Test level they can see how that host was positively/negatively impacted and if any issues were detected, this helps us ensure issues are ironed out prior to rolling into Production.
Playground is limited to Dynatrace Administrators where 2 hosts live which allows us to test new features, process group renaming, and use cases prior to implementing them in the other two environments.
Keep in mind, this is for managed, and within managed you can create as many Environments as you'd like. A Disaster Recovery environment could be created as well with your defined critical applications which will allow you to quickly enable the Disaster Recovery environment with one click as fail over starts to take place.