Create a test environment that is a replica of production so that testing and validation are completed accurately before the Go-Live upgrade on the Production server. This helps you avoid any significant setbacks when moving to production.
Before you begin, complete these steps:
You want your test environment to be as close to your production instance as possible. ThingWorx related backups can be executed at both the datastore level and ThingWorx application level. Refer to the ThingWorx Backup and Recovery Planning guide to start preparing for backups and refer to the original vendor documentation for further details, including the following:
Watch our Expert Session on ThingWorx Backup and Recovery for best practices around:
To learn more about application-level backups such as Import/Export of entities and data from the platform, review How to Import/Export Entities and Data in ThingWorx.
Review Best Practices for ThingWorx Backups, Replication, and Migration to learn more about the topic.
In case your current installation involves other complex customizations, functionalities, and installations such as SSO, High Availability, or any third-party software/hardware:
Ensure each resource working on this objective has access to the right environments and knows how to contact PTC Technical Support.
If you followed a DevOps process, your work should already be backed up. DevOps' critical portion is setting a Source Control Solution such as Solution Central, Git, or SVN that helps you manage code repositories. Your developers should access and back up the code as they collaborate to build your application. If your organization lacks an official DevOps process, take a look at Establish DevOps Practices for ThingWorx. A PTC expert helps your team understand how to implement ThingWorx configuration management and coding and naming standards. We work with you to find the best solution to use your current source code control systems or recommend a new one and promote code from development to test to production.
Create a test environment using your most recent ThingWorx backup which should be replica of production.
Make sure you know:
Document your work and sequence of events followed through this process.
Be sure to contact PTC Technical Support with any questions regarding downloading software, installation, documentation, or moving code & data files to the server.
After the server has been prepared, the very first step is to verify licenses and functionalities.
PTC recommends incorporating three levels of testing into your DevOps:
Move forward through the creation of test plans, test scripts, and tools to validate. Verify they are available in an accessible location with required access. If necessary, go through a trial run to ensure nothing gets stuck.
Ensure you're testing the right items. Run scripts and tools through iterations and record test results. Use assertions as well. Test plans should include any non-ThingWorx or third-party software as well.
Identify your project team with the right capacity to validate the software on the test environment. Ensure you have the right mix of people to test the software thoroughly and completely.
Resources identified could be:
Ensure the resources you identified as testers can access the testing environment, test scripts, tools, test plans, and all processes. They should have proper rights & permissions to run and execute those services and tools as well.
Ensure they are available to begin testing when needed, get approvals from their managers if needed.
Test plans and validation criteria as per user's test limit should be made available to users, if possible. While testing, they should record the results and preserve for prospects.
ThingWorx should run correctly without any failure while turning off the non-ThingWorx software in parallel. ThingWorx should not go down, failing any dependency checks while turning off any non-ThingWorx software.
Non-ThingWorx software could include:
Try making ThingWorx software less dependent on any external software/applications. Make sure ThingWorx is up and running even if any non-ThingWorx software in the environment goes down. If their dependency cannot be avoided, that should be well documented and communicated among team members. Testing around these areas should be well performed and documented. These test plans should be sent to resources allocated for this task. If there are several dependent non-ThingWorx software or third-party software, then test suites/cases should cover all various possible combinations of dependency checks.
Once test resources feel that software is successfully deployed and the validation criteria is showing satisfactory results, inform project members/stakeholders and provide a green light for Go-Live.
Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.