The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
Best practices for implementing a Development to Test to Production environment with VMware Service Manager (2017676)
- Read the article completely before proceeding.
- Ensure to back up your databases and take snapshots of servers before making any change.
- The steps in this article assume that you have not started the development on your Development server yet and are setting up a brand new environment.
- There may be other requirements if you are running in a full or partial load balanced environment. If you are using full or partial load balanced environment and you need assistance or more information, contact VMware Professional Services.
Before proceeding, ensure that you meet these prerequisites:
- Ensure that you have three servers configured with the same version of Windows and patches.
- Load and configure the same version of Service Manager and Rolling Patch on all three servers.
- When testing an upgraded version of Service Manager, VMware recommends you to create an additional environment for this test purpose and do not develop using a newer version of Service Manager than what is running in your Production environment. Otherwise, you may experience issues when running Configuration Portability.
To deploy a Development to Test to Production environment with VMware Service Manager:
- Run a full Configuration Portability Export of your Production system. You may not use the resulting file, but this ensures that all existing database items are assigned a GUID and also lessens the possibility of GUID mismatch.
- Take a backup of the Production database and overwrite your Development database.
Caution: This erases any Development work done since the last time Configuration Portability was run on the Production environment.
- Log in to your Development environment and verify that the database contains the latest Production data.
- Perform all Development in your Development environment.
Note: Do not perform any development, such as adding extension fields, screen sets, or modifying screens, in your Test or Production environment. Creating the same item in two different environments results in different GUIDs for each item and can have disastrous results when running your Configuration Portability Import.
- Take a backup of the Production database and overwrite your Test/QA database.
- Log in to your Test/QA environment and verify that the database contains the latest Production data.
- Run a Configuration Portability Export on your Development environment to export any changes you have made during development, including changes made when developing workflows.
- Export any Workflows you have created or modified from your Development environment using the Server Console.
- Import the Configuration Portability file to your Test/QA environment .
Note: You may see non-critical errors that do not always indicate an import failure. These errors can be safely ignored.
- Import the Workflows using the Server Console in the Test/QA environment.
- Test with your Test/QA environment. If changes are to be made to anything created in the Development system, repeat Step 4.
Note: Do not perform any development in your Test/ QA environment.
- After the testing completes, back up your Production database and import the Configuration Portability file to your Production environment.
- Import your Workflows into the Production environment using the Server Console.
- Repeat this procedure to begin a new Development.
You may experience reference number mismatch issues if you add or modify fields in the Production environment and then add or change these fields in the Development environment to match. Reference number mismatch can cause issues while importing Configuration and Workflows. In this case, you will be prompted to select a field while importing a Workflow.
Request a Product Feature
To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.