Managing solutions and the various resources allocated to those solutions is a nightmare. Tacking a test or development environment is just another hassle, right? However, start thinking about the potential fallout from simple human error when vetting hasn’t been completed properly. It’s easy to see the benefits to setting up those environments.
This quarter, the most common question to come through pertains to how a PortalGuard environment should be set up, and I have some strong feelings in that area.
“When prepping for an upgrade to take advantage of new PortalGuard features, is it really all that important to have a test or development server available?
Yes. It really is that important to have a test or development server in place within your PortalGuard environment.
That’s it. There’s no real debate here.
If you want to know why, take a look after the jump!
The Whole Point of a Test or Development Server
It seems obvious to say it, but it is very important to have a testing environment. Testing environments give administrators a space to validate new functionality and ensure that said functionality will stand up to close scrutiny and user exposure. A testing environment also gives administrators a peak at the potential hang-ups of the newest implementation. This peak can be the difference between a happy end-user, and a firestorm on the day of a production release.
Test or development servers for PortalGuard follow the same logic. These environments allow you to validate those features or integrations that you are going to be deploying to your end-users, without the associated risk. If production deployments are tantamount to landmines for your tech department, a test environment offers a nice dry run to ensure these particular landmines are the non-explodey kind.
What Happens When Things Go Wrong?
When you opt to move straight to production, the own-us is on you if something goes wrong. That’s not to say you’ll necessarily cover every little tidbit that your end-users will find, of course. That is practically impossible. However, if you skip the testing phase, you are more likely to be blindsided by an issue that otherwise would have been a simple thing to address.
Production issues add a whole new level of stress to otherwise simple procedures. Something that takes ten minutes to test, reproduce, and resolve in a testing environment can easily bring the whole system down for an hour in a production environment. It’s silly when you think about it: Why not just resolve those issues ahead of time?
Best Practices and Comfort-Level
Testing new features and integrations in a non-production environment also ensures that the support and administrative teams are comfortable with what the end-users are going to utilize. Comfort level is a huge benefit when supporting a new solution. High comfort levels allow for quick, effective resolutions to the minor issues. These are the issues that users will absolutely be bringing to your support desk.
Of course, it’s worth mentioning that testing before deploying is a widely acknowledged best practice in the tech industry. New features or integrations for PortalGuard should be considered a fresh ‘Production Roll-out'. You wouldn’t roll-out the entire product without testing, would you?
In conclusion, I’ll keep it simple: Testing before deploying is Good; Deploying without testing is bad.
If your experience differs, I’d love to hear it!