CA Release Automation Migration Best Practices

Products

CA Release Automation - Release Operations Center (Nolio) CA Release Automation - DataManagement Server (Nolio)

Issue/Introduction

Are there any best practices relating to the migration/replacement of our CA Release Automation Management and/or Execution Server?

This article is meant to highlight points to consider when migrating a CA Release Automation Management and/or Execution Server. Migration is used in different ways. In this article it assumes you want to move either the CA Release Automation Management and/or Execution Server to a different machine.

Environment

CA Release Automation 6.x

Resolution

Action Management:
I'm not sure if you installed any non-out of the box action packs into your environment. But if you did then you might find that steps inside of your jobs gets cancelled. This article describes how to resolve those kinds of issues:
cancelled steps during a deployment

One option to avoid the cancelled jobs might be to backup/restore the nexus sonatype repository. A link under the artifact management section below is included to help with this Nexus Sonatype task.

Artifact Management:
Before following these steps it is recommended to first backup the folder/files (or vm) so that you can revert should things not work as expected.

The link below is the recommended procedure for backing up and restoring a nexus sonatype repository. This can help avoid cancelled steps in your deployment jobs (if action packs were installed) as well as access to any artifact files that might have been registered to the local artifact repository used by release automation.

How to Back up Nexus for Active/Standby Failover

Agent Management:
When migrating CA Release Automation servers it is recommended to identify if execution servers will also be migrated. If the idea is to migrate/replace old execution servers with new execution servers then it is recommended to identify a strategy that works for your situation and what that involves so you can plan accordingly.

Multiple Execution Servers.
- If you have multiple execution servers then you can easily bring up the new execution servers that will replace the old execution servers and then move the agents (via Automation Studio -> Agent Management) from the execution server it is reporting to now to the new execution server. Steps on how to complete this can are available in the product documentation, here: Change Execution Server for an Agent
All-In-One Management and Execution Server.
- If you have an all in one management and execution server then there will likely be more manual effort involved (unless you use some kind of configuration automation tool like Ansible or Chef). The reason is because there the old and new system shouldn't be running at the same time which would be necessary to use the steps outlined in "Change Execution Server for an Agent". The CA Release Automation services on the new management server and old management server should not be running and pointed to the same database at any time. Once the services on the new management server is ready to be started the services on the old management server should be shutdown first. Then start the services on the new management server and proceed to manually configure your agents to point to the new server (unless the new management server uses the same hostname/ip).

To manually reconfigure your agents to point to a new/different execution server you will need to access the <AgentInstallDir>/conf/nimi_config.xml file and update the supernode for that agent. As the name of the file suggests it is an xml file. The xml path to the list of supernodes is: config/nimi/keepalive/client/supernodes

This information (its xml path) and some additional information about this file on agent (and execution) servers and how the connections are made is available here: Execution Server High Availability and Scalability

Management Server:
To prepare a new management server to replace an old management server the following is recommended:

Make sure that you seutp the new management server using the same version (and patch level) as the old management server.
Do the management server installation (custom install) on the new management server system. During the custom installation there is an option to skip the database setup. Skipping the database setup is recommended. Alternatively you can choose to go through the database installation. If you choose to go through the database installation then care should be taken to not point the installation to the existing database. If you do then it may cause irreparable damage/corruption to the database. If you choose to go through the database installation be sure to point it to a new/unique database.
- If you do decide to skip the database setup then you will need to manually configure its connection to the database. Updates to both of the files below will be necessary. More information on these files can be found here: Manually Configure Communication with the Database
  1. database.properties file: which is used to define which database driver to use
  2. distributed.properties file: which is used to define the database connection properties, ie username, hostname, port etc..
- If you decide to go through the database setup and point it to a new database on a similar database server type (ex: MSSQL) then you should only need to update the distributed.properties file since the database.properties file will already be setup to use the appropriate driver. Update the distributed.properties file to point to the correct database hostname, port, database, and user information.
Once the new management server is installed and pointing to the existing database do not start services on that management server until you have shutdown CA Release Automation services on the old server.

Additional Information

These links are meant to hep provide as much additional information as possible.