Following the advice of this article, I’d like to set up a new Octopus Deploy to test my upgrades. Setting up the new instance is easy. How do I get projects over from my production instance?
There are two options when copying projects from one instance to another.
Option #1 Migrator
Octopus includes a migrator tool to make it easy to copy projects from one instance to another.
The migrator has the following pros:
- Supports sensitive variables
- Simple command to export everything
The migrator has the following cons:
- A user must be logged into the VM running Octopus Deploy to run it.
- It requires the user to run multiple steps. Export from production instance of Octopus Deploy, then import into test instance of Octopus Deploy.
- Unless you include the following flags in the export command, everything about the project will be exported.
--ignore-history,--ignore-deployments,--ignore-machines - It is very heavy handed in its approach. It assumes the destination should match the source. This includes all environments.
Option #2 Space Cloner
The space cloner is a script recently added to Octopus Labs. It was written with the idea of wanting to clone a project, or entire space, from one space to another or one instance to another.
The space cloner has the following pros
- Fine grained control over what is cloned and what isn’t cloned. If you don’t want to clone production you don’t have to.
- Intelligent process cloning, it will try to merge the deployment process from the source instance and destination instance. The migrator will overwrite.
- Don’t need to be logged into the instance. It uses the API rather than direct connection to the database.
- It doesn’t overwrite existing items such as environments, lifecycles, and variables. If it sees the destination already has those matching items it will leave them alone.
- It was written for this use case in mind.
The space cloner has the following cons
- It uses the API, it cannot read sensitive variables. Those will have to be re-keyed.
- It doesn’t clone everything. At the time of this writing this is what it does and doesn’t do.
- It matches everything by name. If you change the name of something in the source it will think it is a new item in the destination and create a new copy.
Option #3 Full instance clone
Following the steps in this doc it is possible to create a full clone of the instance.
The pros to this approach is everything is the exact same. The con to this approach is everything is the exact same. There is a risk of a deployment running on the cloned instance that could affect production targets. It is possible to disable all the targets in the cloned instance using the API.
The recommendation is to research the options to see which one fits your needs the best.
Other recommendations
When setting up a test instance, try to eliminate as many variables as possible. Use the same SQL Server version, the same version of Windows, and so on. This will allow for upgrades of not only Octopus Deploy, but specific dependencies. Install a Windows patch on the test instance and verify everything works. Or, move the database to a new version of SQL Server and test that.