Runbook Tenant Settings Lost When Copying a Project

I have a project that is the template for my new projects. With that project I am using tenants to support blue/green deployments. When I copy the project all the tenants are not in the new project. So I add them back in.

But then I have to go to any runbooks that run on a tenant and enable each one to run on a tenant (on the settings page for the runbook). This is because when the copy happens the runbook is reset to the default of not running on any tenants.

Is there a way to actually copy a project? Fully. With all the settings intact?

Or do I just have to go re-setup all the tenant stuff each time I copy a project?

Hi @OctopusSchaff,

Thanks for getting in touch! The behavior you’re seeing here is currently as designed. We took the stance that cloning a project should only clone the things “within” the project and won’t touch anything else that references the project, like tenants. We didn’t think it was a safe assumption to make that by cloning a project you’d always want the new project to be automatically connected to the same tenants, with the same tenant variables, etc.

Sorry I couldn’t give you better news for your use case, but please let us know if you have any further questions or concerns going forward!

Best regards,

Kenny

We took the stance that cloning a project should only clone the things “within” the project and won’t touch anything else that references the project

OK. Though I will admit that it seems odd to me. Cloning will clone references to Lifecycles, Environments, Script Modules, Step Templates, Workers and Targets. All of which are outside the project.

Still, I admit I am not using tenants the way they are indented. (I am using them as a workaround for Octopus not having support for Blue/Green deployments.) So, it may be that if I really had actual tenants, I would like it setup this way.

It sure would be nice if there were actual support for Blue/Green deployments in Octopus. It is confusing that a product that is all about deployments does not have any features dedicated to this very common style of deployment.

Hi @OctopusSchaff ,

Thanks for following up, and for your input! That’s correct, but the references to lifecycle, environment, etc. are in the project, where tenants themselves need to be connected to a project, and their variables are defined on the tenant.

Very valid points on the blue/green deployments, which I think we would all certainly agree with. There has been talk in the not-too-distant past about significant improvements/native support for blue/green so we’d love to have a better story on this in the future. While multi-tenancy is a way to model (workaround) this, there are a couple other ways I’ve seen blue/green be modelled. Probably the most common is by using a blue environment and a green environment. The following knowledgebase article I think does a great job summarizing some various models.

I hope that helps in some way!

Best regards,

Kenny

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.