So a question now that we are in 2024. How do you let users access your test environment?

[Valentine_Toka1]

Happy New Year!!!

With the ability of remoted access.  Citrix, Azure Cloud, VM's and much smaller desktop profile machines are becoming  popular.   I am just wondering if others had this thought.

Is user access to the test environment separated from your production environment?  Do you allow the Thick, Outlook, Thin, Unity client to be available on your end users desktop in production which gives them choices to connect to dev, test and production via a dropdown list?

If so,  how do you overcome the possibility that a user was using test OnBase to do production work.   My choice was to keep the users separated by using a test machine to access the  test environment.   Simple and easy but getting feedback it takes to long to get the user access to test to do the work.  I like keeping a VM's with a similar production built workstation/remote workstation.  However, with the availably of having additional lines added to the OnBase config file(s).  The access is much easier to get them the need to test much sooner.

I want to be fair with my recommendations as best practice but I know we all have good deployment ideas that may work better than others.

As always, this community is the best for getting information.

Val

[AdamShaneHyland]

Hi @Valentine Tokarczyk ,

The best scenario for test is like for like.  That means to have a non-PROD test environment which mimics your PROD environment as closely as possible.  However, having any test environment has value. 

The question becomes how adverse are you to risk?  If you aren't, then I would recommend getting a test environment as close to your PROD as you can in order to as best as possible thoroughly test your solution prior to making any changes in PROD.  That being said, the reality of this best practice usually doesn't align with the cost to implement it and therefore necessary compromises are made.  

Knowing the gold standard best practice is to mimic your PROD environment, if this is not attainable, the next step is to start making compromises to get as close as possible to it.  For instance ...

• Do you need Disaster Recovery in your non-PROD environment?
• Do you need High Availability (load balancing) in your non-PROD environment?
• Do you need all of your respective web apps (e.g. OnBase Web Server, Application Server, etc) running on different machines?
• Do you need to offload certain processing to individual servers OR can they be on a single machine to prove out functionality compared to proving out load?

Hope this helps.  Best wishes.

[Valentine_Toka1]

Thank you much for the information.   You are actually correct with my set-up.   I came as close as possible without adding to much.

Do you any importance to where the testers test or does it make more sense to have a tester connect to a test workstation that mimics production?  

We have the ability to allow users on their production machines that they work with day to day to point to the test environment.   I myself do not like this as this can lead to additional errors that may not be able to be identified just because it's a setting (I.e. web browser trusted sites, proxies, certificates, user privileges and patches).   However, this is me and the way I have worked with OnBase for a long time.  

I appreciate your time.

Val

[AdamShaneHyland]

Hi @Valentine Tokarczyk ,

Reviewing old posts I came across this one and noticed that you have an question that did not have a response.

From a testing perspective, they have use their workstations unless there is a specific need why they shouldn't.  However, if it makes sense to test from a separate machine, you could setup a virtual machine for users to connect to allowing them access to test out the solution without being on their machine.  There are other virtualize solutions like VDI or Citrix that could be helpful too.

Best wishes.

[Alex_Rath]

We only use Unity (for end users), and are a small organization, so it's pretty simple for me.  The only time anyone really needs to access test (other than some users who need it for testing with the Core system that feeds into it), I just manually modify a user's configuration file to allow a Test option during project testing for new efforts, then remove it when testing is done and the project moves to PROD.