We’re currently attempting to migrate our existing configurations (projects, variablesets, lifecycles, certs, script modules, project variables, environments,etc.) from an existing Octopus server to a new Octopus server via powershell script and Octopus’ REST api. The documentation provided in https://github.com/OctopusDeploy/OctopusDeploy-Api/wiki allows us to access each of the resource in a fairly straightforward manner. However, we do get a few errors every now and then when the api performs “foreign key” checks.
Let's take this scenario as an example. Server A and B are the existing and new Octopus servers, respectively. We typically would start by copying the LibraryVariableSets by issuing a GET on http://A/api/libraryvariablesets/all, looping through each and every library variableset returned as a PSObject and posting this PSObject as the body on the subsequent POST request to http://B/api/libraryvariablesets. I do notice that they'd be successfully created but the Id values for the same name would be different between the Server A and B for the same variable set name. Is there a way to ensure that the Id values are preserved during a POST request? I'm able to copy the variable sets without any problem other than the Id differences. However, when I follow it up by copying projects from server A to B, I do get an error indicating that the variablesets referenced by the project we're creating do not exist on server B. Is there any documentation we can use to find out the relative order in which we must copy the resources from one server to another? How do we preserve IDs of resources copied from server A to B? Are resource names always unique? We've also considered just backing up the database and restoring it but couldn't because we are actually performing configuration transformation/mapping. Specifically, we are: - Reducing the 43 environments from server A to just 6 (DEV, UAT, DEMO, STG, PRD, TEST/QA) by splitting it to a tenant and environment combination on server B. Currently, each environment is created for each unique (customer or team) + (DEV or STG or PRD or UAT) combination and this has made the dashboard very difficult to use. For example, an environment called UAT - A will be mapped to environment UAT and tenant A on server B. - When migrating the variable sets from server A to B, we want to replace the environment scope (as defined on server A) with the new tenant and environment scope. - When migrating projects, any step belonging to a project that has an environment scope on server A will be replaced by corresponding environment and tenant scopes on server B. - On the final step, we will copy machines from server A to B and updating its environment scope to the corresponding environment and tenant scopes on server A.
Is there a better/quicker way to go about this process? How can we pair up the existing agents running on the machines so they would register themselves to server B with the same role as before but assigned to a new environment and tenant value from server B? Has anybody done this via powershell remoting or sysinternals psexec?