In our company we would like to automate process of creating environment with deployed our whole system (clone of production releases). Costs of doing this now is very high (deploying something about 100 components + databases).
Is it possible to “clone” production environment with releases (it will create environment with successful releases, but without deployment target)? So when we connect new deployment targets to newly created environment octopus will deploy needed components.
Maybe something similar is achievable through api? I didn’t find a way.
Thanks for reaching out! Creating exports of your data is totally achievable with the use of our data migration tool. That will allow you to export your entire instance. You can then script it to delete any folders you do not want to be imported.
Though in your case, the partial export option sounds like it would be the best. It gives you more control over what you export, so it’s great when you only need Project related data. For example, you can use the parameters
--ignore-deployments to get only what you need.
I hope that helps! Don’t hesitate to get in touch if you have any further questions.
So if I understand correctly:
- I can create new environment (DEV10 for example)
- Configure variables for new environment
- Export project data with partial exports
- Edit exported data, in such a way, that there are successfully deployed releases for new environment in this project (for example copy from DEV09)
- Import project
- Attach machines to new envornment
- Octopus will deploy components using Machine becomes available for deployment trigger
I didn’t try anything yet (documentation was down) and just want to be sure.
I exported data using partial-export (Octopus.Migrator partial-export --projec t “ServiceName” --directory=“C:\OctopusExport” --password=“pass”) but I don’t see any data containing releases and deployment information
When I specified a release version, I got deployment data, but i really don’t see an easy way to add new “fake” deployment to new environment
Thanks for following up! I’m going to change gears a bit here, as I suspect there’s a better solution for you. Let me know what you think. Automatic Deployment Triggers may be better suited to handle adding more Machines. You can configure these Triggers to automatically deploy the currently successful deployment of your Project once a new Machine is created.
- It would eliminate the need for partial-exports
- It’s automated, so it’s easier and quicker
You can read more details about these Triggers in our documentation: http://docs.octopus.com/display/OD/Automatic+Deployment+Triggers
Being able to automatically trigger these deployments to targets once they become available approaches the auto-scaling idea nicely. In Octopus 3.4 we added support for Elastic and Transient Environments, and combining that with the use of Triggers can be a very powerful tool.
If I have misunderstood any part of your setup, could you explain the process you’re trying to achieve in more detail?
The problem with Automatic Deployment Triggers is, that when I create new environment (no deployments yet) and connect machines to it, ADT will not work. I need firstly deploy something (have successful release) and then, when I attach another machine it will deploy the successful release.
Our goal is to automate creation of new environment. For example we have 10 development envs (one for each team) and we want to create 11 team. New team needs its own environment. We would like to deploy to this environment all components with production versions. So this is a little like cloning production environment.
At this moment I have created scripts in powershell, which are using Octo.exe to get latest releases (using dynamic dashboard api) and then deploy them to new environment. But maybe there is better way.
Thanks for the additional information.
If you’re dealing with environments that have not yet been deployed to, you can create an auto-deploy release override using the Octo.exe utility or the Octopus.Client library. By creating both a new release and an auto deploy override, when new infrastructure is provisioned, you can indicate to Octopus that the new release should be deployed to the new infrastructure.
The “Overriding the release used for automatic deployments” section of the Keeping deployment targets up to date documentation will help explain this in more detail (this part relates to you: “maybe you have a release, but have not yet deployed it anywhere”. There is also an end-to-end guide in the Immutable Infrastructure documentation … see the section called “Automatically deploying a new release”.
Let me know how you go.
Ok, thanks, I just hoped, that there is better way, than using api (or octo tool) and specifying deploy (or deploy override) per project.