Import for non-default scope

ruf-u
(Maxim Tiutmanov) #1

I need to move a project configuration from the DEV octopus server to PROD. In DEV, the project is located in the default scope, while in PROD it should be located in a non-default one. I am using the partial-export functionality of the Octopus.Migrator tool. I don’t see how I can scope my import to the particular space on the PROD Octopus server, so that my project with all its dependencies will appear in the (already created) non-default scope on the PROD.

Is this possible?

(Nick Josevski) #3

Hello,

Thanks for getting in touch. At the moment there is not a way to achieve this.

The migration tools part of Octopus do not yet support moving projects and related data between Spaces. We are working towards delivering this capability but we don’t have a timeline on when it will be ready yet.

Projects in Octopus can be connected to everything. Moving a Project means the application must be able to check every possible related item that can be linked to a project and have a way to determine if the item is the same on the destination and act accordingly.

We aim to build a very robust and safe to use feature to allow customers to do these migrations with confidence it will just take us some time.

Regards,
Nick

(Maxim Tiutmanov) #4

Hello Nick,

Thanks for the reply. I understand that there is no general mechanism for moving projects between spaces yet, but I see from your documentation that at least some tooling exists. I am trying to make this work with space parameter specified, but I have problems with step templates. When importing a project, the octo.exe tool checks all the prerequisites (environments, channels, step templates, etc., all these I have copied manually), and it seems to me the tool looks for step templates in the default space rather than the one I specified in the space parameter. So step templates seem to be interpreted as “shared” throughout all the spaces by the octo.exe tool. I checked the code for the octo.exe, there seems to be some special logic for step templates.
Am I missing something? Is this a known behavior?

(Nick Josevski) #5

Hello,

Going over what you’ve described unfortunately it’s not supported. That space parameter is the misleading part. It’s there for consistency. It doesn’t signal migrations support Spaces - it’s a common property not part of the import command https://github.com/OctopusDeploy/OctopusCLI/blob/c3b8420fde34f8755dae93e962486d2cf66d35e4/source/Octopus.Cli/Commands/ImportCommand.cs#L22

If I read this part of your last message carefully you do have 2 different spaces, or at least because on Prod it’s not the default it becomes an unsupported case.

In DEV, the project is located in the default scope, while in PROD it should be located in a non-default one.

We currently only support moving data between 2 servers where they are basically the same, we only intended to have the migrator work for existing scenarios.

Trying to use Spaces is not an existing scenario, and isn’t supported because we are trying to focus our work on a completely new migration tool instead of trying to patch the existing migration tools to work with the changes introduced in Spaces.

If you need to use the migrator to move data between to instances, the only supported approach is moving data between the 2 default spaces on both instances.

I’m sorry if this has caused you a lot of wasted effort, we really do want to ship a great new migration tool it’s just very complicated.

Regards,
Nick

(Maxim Tiutmanov) #6

Ok, looking forward for you guys to implement a new tooling for migration.
In the meantime, here is the approach I currently use:

  • Copy all project’s dependencies (step templates, package feeds, environments, lifecycles, variable sets, etc.) to the target space on the target server (PROD).
  • Use the export/import functionality of OctopusCLI for promoting the project configuration to PROD server/space. There were subtle issues with scoping it to the correct space on the target PROD server, but I overcame it by slightly changing the code for locating step templates and nuget feeds. I guess I should suggest these changes as a PR on github, will do so when I have time.

This allows to promote the project configuration (actions for deployment, project variables) on regular basis. The project dependencies should be kept in sync manually though.

1 Like