Testing upgrades on a cloned virtual machine
You can perform a test upgrade of your production server that is hosted on a virtual machine (VM).
- Stop the production server.
- Stop the production VM.
- Clone the production VM.
-
Clone the database:
Contact your database administrators (DBAs) to clone the database. Your DBA must backup the existing database and restore it to a new database that can be accessed from the newly cloned IBM® UrbanCode® Deploy server. If more assistance is needed than your DBA can provide, use your support case for assistance.
-
Clone the application data (appdata) folder:
The location of your appdata is defined by the
server.appdata.dir
property in the server's installed.properties file.Most application data folders are mount points to an external file system. If your application data folder is external to the IBM UrbanCode Deploy server, clone the application data folder. Point your cloned IBM UrbanCode Deploy server to the cloned application data folder to avoid using the application data folder of your production server.If your application data folder is large and you do not want to clone it for your test environment, you can skip cloning the application data folder and start a new one. If you chose not to clone the application data folder, no production component versions can be used nor can you view any production step output (both are stored in the application data folder). New component versions must be created to deploy.If you choose not to clone the application data folder, copy the other application data folder files like:- Custom email notification templates, if you want to test them after you upgrade the clone.
- The plug-ins directory.
- If you want to verify the clone's health before you perform an upgrade, copy the patches. During an upgrade, IBM UrbanCode Deploy turns off any patches by appending ".off" to the patch name.
-
If IBM UrbanCode Deploy is
configured to use S3 storage, which is available starting with v7.0.5, clone the
S3 bucket if you want to use the same component versions artifacts as the
production server.
Note: You can skip this step if you prefer to create new component version artifacts.
- Start the production VM.
- Start the production server.
- Start the cloned VM.
-
Modify the cloned database.
-
For high availability (HA) configurations
only:
Remove the web cluster configuration from the database, if applicable, by deleting all the contents of the
ds_server
table. If you need assistance deleting the contents, contact your DBA.Note: Versions prior to 7.0.0 do not have ads_server
table. - To stop automatic component version imports, run the following SQL to update the components in the database:
update DS_COMPONENT set IMPORT_AUTOMATICALLY='N' where IMPORT_AUTOMATICALLY='Y';
-
For high availability (HA) configurations
only:
-
Modify the appropriate property values in the clone’s
installed.properties (and
secured-installed.properties file in newer versions)
file.
The following properties must be modified to the values that are appropriate for the cloned server:
Property Description hibernate.connection.url The URL of the cloned database. hibernate.connection.username The username used to access the cloned database. hibernate.connection.password The password of the user used to access the cloned database. Note: The password is stored in plain text until the cloned server is started. After the cloned is successfully started, the password is encrypted. In later versions of IBM UrbanCode Deploy, this value is stored in the secured-installed.properties file.server.external.web.url The URL of the cloned server. install.server.web.host The hostname of the cloned server. server.appdata.dir The location of the cloned application data folder. agentcomm.uri Update the hostname with the clone's name. encryption.keystore.alias Update only if you copied the encryption.keystore from production to the clone. Set it to the same value as the production server's value. If you are using S3 storage, you might have to modify the S3 storage properties, or ensure they are correct for your cloned S3 bucket:codestation.s3.bucket – the bucket name codestation.s3.region – the region codestation.s3.user – the API key codestation.s3.url – custom URL codestation.s3.signerOverride – signature algorithm codestation.s3.enablePathStyleAccess – true or false codestation.s3.password – API secret
-
Start the clone server.
Note: Use the machine IP address to access the IBM UrbanCode Deploy UI for the next step.
-
Make additional changes to the clone.
-
Click Settings > System Settings from the web UI:
-
Set the External Agent URL and External User URL.
-
Remove the Mail Server Settings information.
-
- Delete any scheduled jobs from the calendar.
-
Create new agents for testing.
Although production agent information exists in the cloned database, the production agents show offline in the clone because the agents are configured to connect only to the production server. To test deployments after you upgrade, you have to create new agents for the cloned environment.
- To license the clone, contact your IBM sales representative to obtain a temporary license.
-
Click Settings > System Settings from the web UI: