I am trying to import a project from 2018.8.12 into 2018.9.12. The project import errors with “Version rules must specify a package step”. If I remove the rule and import again then it works just fine. The project was exported with a partial-export using the Migration tool.
We keep our Octopus projects in Git as pared down partial exports along side the software they deploy. When we are ready for a release we update the production server by importing the relevant project. This process has worked fine until we tested with 2018.9.* when we started getting import errors on our version rules.
Thanks,
Paul
Hi, Thanks for getting in touch! I’m sorry to hear that you are seeing problems with the Octopus Migrator.
One thing to note with the migrator is that we generally recommend that the version of Octopus between the Source and Destination servers in a migration are exactly the same, or at least very close.
It’s quite possible that the version miss-match is what’s causing you problems with the import here. For more information on Octopus migrator, please check out our Migration API which uses the same Migrator.exe command line tool under the hood.
If you’re interested, one other method of keeping the configuration of your Octopus Server in source control could be to use a fairly new, open source Octopus Terraform Provider written by a member of the community, MattHodge. While we don’t support the provider, there’s a chance it could be a good fit to keeping your Octopus Server config in source control as opposed to having migrator exports.
I look forward to hearing if you have any questions here
Kind regards,
Lawrence.
It would be more helpful, if the Migrator is not going to support an upgrade scenario, that the import fail immediately with a version check of the metadata.
As to the Terraform Provider, we have taken an initial look at it and it is promising, but you are asking customers to add yet another piece to their release pipeline with its associated IT management, learning curve, and expense so that we can protect ourselves from your breaking changes. That’s a tough call for us. It seems like that would be something that Octopus should be taking the lead on.
Thanks,
Paul
Hi,
Thanks for keeping in touch and I’m sorry for the delay in getting back to you on this one! Your feedback here is very helpful!
Currently a lot of members from the Migrator team are on a well deserved break for the holidays but once they’ve returned I’ll be able to pass your feedback onto them.
In the meantime, I’ll keep this ticket open so that I can get back to you with any updates!
Kind regards,
Lawrence.
Hi Paul,
Thanks for your patience here. I’ve passed your feedback and recent experience with the Octopus Migrator on to the team. I’m interested in knowing a few more details about your specific use case with the Octopus Migrator too if possible.
In your environment, would you typically use the exports of your Octopus Projects in source control to restore lost data in the event that your Octopus Server ever has a failure and needs to be restored?
Typically, what would happen to your source Octopus server once you’ve taken the migrator export? Does it get shutdown and destroyed once the export is taken, so that subsequent spawns of an Octopus Server can be built from your code in source control?
I’m asking these questions to get a feel for how you are using this feature because a lot of changes are happening with the Migrator. The good news is that we are planning to introduce some kind of early warning when you attempt to import a non-compatible export, we should expect to see that soon.
While using the Octopus Migrator export is a good way to provide an audit log in source control, we don’t recommend it as a way to provide backup/restore. For more information on this please feel free to check out our documentation on Unsuitable Scenarios for the Octopus data migration. The most recommended way to get a true backup/restore strategy with Octopus is to take Master Key, File Storage and SQL Database backups at regular intervals.
I look forward to hearing your thoughts comments and questions here.
kind regards,
Lawrence.
Thank you for the follow up. The purpose of our storing the partial exports in Git is to keep our production server in sync with our test and development servers on a project by project basis. We intend, as part of the build and release process, for the project to be pulled from Git and imported into the target server.
Thanks,
Paul
Hi Paul,
Thanks for keeping in touch and letting us know how you’re using the Octpous Migrator tool in your environments. We’ve recently updated our documentation on Data migration to help guide the optimal ways to use the migration tooling.
I believe the key thing to note here is that we are calling out that the soure and target Octopus Servers must be running the same version of Octopus Server.
Please feel free to keep in touch if you’re using matching versions of Octopus and still run into problems importing/exporting projects. While I don’t exactly know when we will introduce a feature that will tell you ahead of time if an import is not compatible with the export, I understand that it is something we are thinking about implementing soon.
Kind regards,
Lawrence.