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?
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
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?
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 OctopusCLI/source/Octopus.Cli/Commands/ImportCommand.cs at c3b8420fde34f8755dae93e962486d2cf66d35e4 · OctopusDeploy/OctopusCLI · GitHub
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
Ok, looking forward for you guys to implement a new tooling for migration.
In the meantime, here is the approach I currently use:
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.