Testing upgrades on a cloned on-prem installation

You can install a new HCL DevOps Deploy (Deploy) server and then populate it with data from the production server.

Procedure

  1. Create a host machine that is similar to your production server configuration.
    Note: The cloned server must not be an exact copy of your production environment, but is similar enough to test an upgrade.
  2. Install the same version of Java that the production host uses.
  3. Stop the production server.
  4. 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 HCL DevOps Deploy (Deploy) server. If more assistance is needed than your DBA can provide, use your support case for assistance.
  5. 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 Deploy server, clone the application data folder. Point your cloned 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, such as:
    • 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, Deploy turns off any patches by appending ".off" to the patch name.
  6. If Deploy is configured to use S3 storage, which is available starting with v7.0.5, clone the S3 bucket 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.
  7. Start the production server.
  8. Transfer the Deploy installation files to the clone host.
    Place the JDBC driver JAR file that production is using into the clone system's lib/ext directory so that the same JDBC driver is used by the clone.
  9. Run the same Deploy version installer as your production server, choosing not to install the database.
    The installer prompts you to configure Deploy to use an application data folder. If you do not use an application data folder, this configuration is corrected in a later step.
  10. Copy the contents of the conf/encryption.keystore directory of the production server to the clone’s conf/encryption.keystore location.
    To handle the differences in encryption keys, you can either replace the clone’s encryption.keystore folder after installation with the production one or you can add the production key to the cloned keystore. See Sharing secured properties among servers.
  11. Modify the cloned database.
    1. 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 a ds_server table.
    2. 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';
  12. 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.

    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 Deploy, this value is stored in the secured-installed.properties file.
    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
  13. If you are not using an application data folder, replace the clone server's var directory with the production server's var directory.
    This replacement copies over files like the artifact repository and plug-ins. You can delete the application data folder that was created during the installation because the server does not use it.
  14. Start the clone server.
    Note: Use the machine IP address to access the Deploy UI for the next step.
  15. Make additional changes to the clone.
    1. Click Settings > System Settings from the web UI:

      • Set the External Agent URL and External User URL.

      • Remove the Mail Server Settings information.

    2. Delete any scheduled jobs from the calendar.
    3. 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, create new agents for the cloned environment.
    4. To license the clone, contact your HCL sales representative to obtain a temporary license.