Optimizing Your Solimar Environments: Best Practices and Pitfalls

Maintaining stability and minimizing unplanned downtime is essential for production environments. This summary provides insights on managing your Solimar production environments more effectively, helping you prevent downtime and improve overall performance.

While this can’t cover every aspect of managing Solimar environments, it will prompt you to consider critical aspects and utilize resources like Solimar Support and Solimar University Online (SUO).

Understanding Environments
An environment consists of hardware, software, applications, and connectivity configured to execute your workflow’s operations. Different environments are used for production and support purposes:

  • Production Environment: A clean, high-performance environment responsible for producing work. It must be protected from changes that could cause instability or introduce errors. Automatic upgrades and untested system changes are not allowed.
  • Standby System: An exact duplicate of the Production system, ready to take over production work during downtime. It follows the same rules as the Production environment.
  • Staging System: A clean mirror of the Production system where upgrades, patches, and application testing occur. Once changes pass regression testing, they can be applied to the Production server.
  • Dev/Test Environment: Used by staff to maintain existing jobs or develop new ones. These systems may contain development tools or other software that could affect stability or performance, so they can’t be relied upon as a production stand-in.
  • Recovery System: A mirror of the Production system activated when the primary system is unavailable. It must synchronize perfectly with the Production environment for disaster recovery purposes.

Change Management Process
To ensure stability while keeping your production environment up-to-date, follow this process:

  • Build and test applications in your Dev/Test environment; apply all OS patches and software upgrades here.
  • Keep the Staging environment synchronized with Dev/Test but maintain a clean system without dev tools or other software that could impact production.
  • Push applications, software, and OS upgrades to the Staging environment for extensive testing.
  • After validation, create an image of the fully tested Staging Server environment.
  • Implement any software or OS upgrades to the Production Environment.
  • Migrate the entire server, not just individual applications, when transferring Solimar content.

Following this process reduces downtime risks due to upgrades or other changes.

Best Practices and Pitfalls from Solimar Support
The Solimar Support team has extensive experience and offers the following best practices and pitfalls to avoid:

  • Test any upgrades in a Staging environment before implementing them in Production.
  • Ensure the Staging environment is identical to Production. If changes pass testing there, you can confidently push work to production.
  • Avoid pushing applications directly from Dev/Test to Production, as differences between environments can cause issues.
  • Test applications thoroughly in the Staging environment instead of discovering problems in production or after printing.
  • Regularly practice your Disaster Recovery process; don’t wait for an actual disaster to test it.

Environmental Best Practices
Adopt these environmental best practices to maintain stability across all environments:

  • Keep your environments synchronized.
  • Schedule upgrades during off-peak times or planned downtime.
  • Develop comprehensive regression testing and automate as much as possible. Ensure coverage for various applications and scenarios.
  • Prioritize documentation over tribal knowledge, making onboarding new resources easier and managing Disaster Recovery across different locations.

By following these best practices, you can maintain stable and optimal Solimar production environments while minimizing downtime and reducing errors.

My name is Dan Beery, VP of Product and Strategy Development for Solimar software. When it comes to production, downtime is frown time or should I say unplanned downtime. This presentation presents some pointers on how to minimize unplanned downtime, errors and instability in your production environment. It’s not going to give you all the answers you need for your environment, but I’m hoping it’ll get you thinking about the topic more. Solimar support and Solimar University Online are great resources that can help you refine your plans.

A good place to start is to discuss what we mean by environment. An environment is all of the hardware, software, applications and connectivity configured to execute all of the operations in your workflow. There are a number of different environments that are used for production and in support of production.

Production is, of course, the environment used to produce all of your work. It is very clean, high-performance, and it must be protected from changes that create instability or introduce errors or failures. Things like automatic upgrades are not okay here. No changes can be made to the system without testing them first, In a non-prod environment.

A standby system is an exact duplicate of your production system that stands ready to shoulder your production work at any time in case of production down situation. It is a production environment so all of the same rules apply. Staging systems are a clean mirror of the production system. Your staging system is where you apply things like upgrades and patches. Applications are tested in staging to determine if they work. Once all of the changes have been tested and pass regression testing, they can be applied to the production server. At the end of this process staging and production should be identical protected environments.

Dev/Test systems are the daily drivers for staff who are charged with maintaining existing jobs or developing new jobs for production. They may have development tools, debugging tools and other software that can cause instability, impact performance or otherwise jeopardize production. These are messy systems, so they can’t be relied upon as a perfect stand in for production. That is why you need a staging system.

Recovery is a mirror of the production system that can be stood up or activated for use as required to handle production while the production system is unavailable to produce work. A recovery system must be kept in perfect sync with the production environment to ensure that when it is brought up, it will function perfectly in place of the production system.

This diagram shows the preferred method for making any kind of changes to your production environment. Build and test applications in your dev/test environment. Apply all operating system patches and software upgrades here. The staging environment should be kept in sync with the dev/test as well. The difference is that it is a clean system without dev tools or other software that could impact production. Applications and any software or operating system upgrades are pushed to the staging environment where they are extensively tested. Once they’ve been validated in that environment. An image is made of a fully tested staging server environment. Any software or operating system upgrades are then made to the production environment to make it match. When migrating Solimar content, you should migrate the entire server rather than just moving an individual application. From this simple flow can ensure that your production system is stable and up to date, reducing risk of any downtime because of upgrades.

The Solimar support team has been around for a long time and they’ve seen it all. Here are some of the best and worst practices straight from them.

Any upgrades made to your production environment without being fully tested in staging creates a risk that something will break. Databases, operating system patches, drivers, networking, really anything has the possibility of disrupting production. Some of these upgrades are very hard to back out. If staging is identical to production, and it passes testing there. you can safely and confidently push work into production.

Customers who don’t have a staging environment are forced to push applications directly from dev/test into production. This can be risky. Many times. dev/test environments have tools, libraries and other components that are not available in staging and production. So, the developer runs the app and it works fine there, then they push it into production and it doesn’t work because of a missing or a different version of a library installed as part of the development environment. Remember, these environments can be complicated. Opening apps to a staging environment and beating it up there allows you to catch issues there and not in production. Finding out the hard way may mean on the shop floor after it’s printed, or worse yet, in the customer’s hands.

Disaster is no time to test your disaster recovery process. It must be exercised and practiced on a regular basis to ensure that the people, processes and technologies are all working. Calling for after our support could be an awkward and expensive way to get things running again. The safe route is to make a full copy of your Solimar server, and pushing that to a shared storage location. It will always be available should you need to stand up a recovery server at another location. Regularly rehearsing DR procedures is necessary not just for the technology, but especially for the people involved in the process.

Let’s wrap up with some environmental best practices. Be diligent about keeping all of your environments in sync. Plan for upgrades. Try to find off peak times or times when you can have planned downtime. Build comprehensive regression testing. Automate as much of it as possible. Make sure you have coverage for as many applications or scenarios as possible. Tribal knowledge is no substitute for good documentation. Documenting and testing all of your IT processes makes bringing in new resources and managing DR in different geographies much easier.