Looking for guidance in multi project and multi deploy setup

Hi,

we are using octopus deploy currently to deploy 2 web sites to Azure Web Apps across multiple projects.

Currently we are setting up environments for each project so it is like “ENV-PROJ1-DEV”, “ENV-PROJ1-TEST”, “ENV-PROJ2-DEV”, “ENV-PROJ2-TEST” and so forth. Then we have roles like “Web” and “Admin” assigned to each azure web app deploy step so it deploys the proper package to the proper web apps based on roles. Each of the environments have different deployment targets associated with the proper roles.

As the number of projects grow the amount of environments becomes un-maintainable, not to mention the overview becomes impossible to read.

In an ideal world we would like to simply have only 2 environments like “DEV” and “TEST” and only 2 roles like “Web” and “Admin” and uses those across all projects, but we are not really sure how we can associate different deployment targets with this setup. We would like:

PROJ1 -> environment “DEV” in role “Web” first deploys to “TARGET1” and in role “Admin” to “TARGET2”, then when the release is promoted to “TEST” environment it will deploy role “Web” to “TARGET3” and role “Admin” to “TARGET4”

PROJ2 -> environment “DEV” in role “Web” first deploys to “TARGET5” and in role “Admin” to “TARGET6”, then when the release is promoted to “TEST” environment it will deploy role “Web” to “TARGET7” and role “Admin” to “TARGET8”

and so on with all the other projects. Is this something that is possible to do or are there other recommended ways of doing this? All projects are seperate projects, because of different codebases and packages, but concept is the same.

Regards,
Thomas

Hi Thomas,

Thanks for getting in touch! I’m sorry for the delay in getting back to you here. It sounds like you could be looking for our Tenants feature here.

Tenants enable you to minimize your overhead when deploying the same project to multiple different targets on the same environment. If your projects share the same concept, but differ between packages and variables, you can create a Tenant for each target and have Octopus create a separate deployment task for each Tenant.

We have some detailed documentation on our Tenants feature which I recommend looking into.

Another way to consider Tenants is as customers. If each customer needs the same deployment, but with a different package, different connection strings, and different variables, you can create a Tenant for each customer. You then have the ability to define Tenant specific variables which can be created in your project and have values set in a connected Tenant. During deployment to your Tenants, a new deployment task will be created for each Tenant and the variable values set inside your Tenant will be used.

This lets you keep the amount of Projects, and Environments to a minimum and easily make changes to each individual Tenant.

The above documentation I linked has a lot more detailed information and examples on how you can implement Tenants into your deployment.

If you have any questions, thoughts, or get stuck here, please let me know.

Best regards,
Daniel

Hi Daniel,

Thanks for the reply. I have been looking into the tenants feature and have created multiple tenants and connected them to a project. Then I created some project variable templates and filled in the values in each tenant. I for example create a variable called “nuget-package” and tried to use this variable in the deploy web app process and entered #{nuget-package} for the package-id for deploying an azure web app. I also previewed the variables under the project and can see the variables are correct for the tenants.

But now I am kind of stuck, if I click create release it doesn’t seem to resolve the variable name for picking a package to deploy, so not sure what i should do here. nuget packages could differ between tenants, so this was my hope i could do it like this. But perhaps I am going about this the wrong way?

Hi Thomas,

Thanks for the update! Currently the option to use packages as a variable is not as developed as we would like. Whilst it is possible, there are some things to keep in mind, and the functionality is limited.

Octopus generally collects information about the package and package version at the time of release creation. Using a variable for the package name somewhat gets around this, but Octopus will still need to know which version of package it needs to use.

We have a section covering this in our documentation on Dynamically Selecting Packages at Deployment Time. It covers this in some detail and also provides a link to our current open GitHub issue to improve on this feature.

One method you could use is to have the release number the same as the package number. This would let you create a release with the package version set as #{Octopus.Release.Number). This option can be a bit temperamental and cause the deployment to fail or deploy the wrong package if your package version is not kept in sync with the release number.

The other option would be to manually enter the version number for the desired package at release creation. This way, you set the package name value on the Tenant, then you only need to supply Octopus with a version for the package to use.

As noted in our documentation, this is not a very well supported method with Tenants, though it is possible.

If this does not help, or if you have any questions at all here, please don’t hesitate to let me know.

Best regards
Daniel

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