**We are self-hosted**
Can anyone help me come up with a user friendly distinction between Sandbox and TEST? In my previous work experience we only had one - it was called "Training" - and we used it to train some users and as a Sandbox as well. More often we used it as a Sandbox. Now that I am using Tessitura I struggle with defining the difference between the two environments.
Thanks,
Ashley Elliott
Database Administrator
St. Louis Symphony Orchestra
314-286-4198
ashleye@slso.org
Hello, Ashley!
It’s very much up to you and your organization — there’s no hard and fast rule. I’ve always maintained two non-production environments of Tessitura: a TEST or STAGING environment that as closely mirrors my production environment as possible. This serves a few purposes: 1/ it’s the environment staff can go play in (frequently refreshed from live) and not worry about messing things up — I also tend to give power users admin or higher-level permissions, so they can learn more about the application; 2/ it’s a disaster recovery option should something happen to production (less useful these days in a VM world); 3/ it’s a staging for new dev work prior to launching to production.
And then I have a DEV environment, which is my playground. I’ve always kept my third environment as Tessitura in a box — a single, beefy server. I deploy new major versions of Tessitura here for power user and beta testing. And I muck about screwing things up in this environment for my own occasionally nefarious, always undiscernable purposes. (Note: I strongly encourage all self-hosted environments to get on board with limited testing of Service Packs and faster delivery. Tessitura has made huge strides in terms of reliably delivering tested SPs for major revisions.) For instance, right now, our DEV (I inherited the name BETA) environment is currently testing out and remediating issues related to migrating to TLS 1.2 ODBC connectivity.
Hope that helps!
DGomez
Wow! Thank you for this reply. It was truly helpful.
Hi Ashley,
We have a UA and a DEV environment. In a perfect world, we develop in DEV, move it to UA for User Acceptance testing and then move it to LIVE. We also use UA for new staff training. New users play around in UA for their entire training period.
In the past number of years, we've not really followed the 3 levels but have used DEV and UA interchangeably. We'll roll to one of those environments, do an upgrade, do the testing and then move it t LIVE rather than doing the 3 levels.
As Daniel pointed out, there are multiple ways to do this. In our case, we have a test environment that is automatically refreshed from live once per week. This gives a place for our staff to try things out on fairly up-to-date data. We also have special dev/test environments that we fire up for specific projects - we currently have up to 7 of these. (It's rare they are all active at the same time though.) This allows us to refresh the Tessitura database based on the needs of a project without impacting other work. Note that we do not use all components in these environments. For example, we only have two Tessitura Analytics environments (live and test).
Best of luck to you!
David
I'd like to know how you setup your automatic weekly refresh. I am currently doing a manual monthly refresh of Test. Can you give me any information on automating that process?
Thank you!
Ashley