I have played with Octopus and it has served us well - so now we are ready to go all in. However as I try to grasp multi-tenancy and versioning, I have some obstacles that are messy and I loose overview. So what I would like, is to tell you our use-case / what we want to do, and hopefully you can advice on how we should approach this. You can imagine that we have a fresh install of Octopus - so I’m really after “what would you do” kinda advice. Complete with all steps to take
We are running Octopus 3.4.7 and Teamcity 10.x
We have a website that is delivered from teamcity to octopus on each build. The versioning from TC is like “Website.1.1.2-dev-236” where “dev” is the branch and the last number is the TC incremental build number. Some valid versions would be like:
"Website.1.1.2-dev-236"
“Website.1.1.2-rc1-240”
This website must:
Push to DEV environment if the version contains “dev”.
Each night, DEV must be promoted to QA environment, Tenant1 and Tenant2.
Push to QA environment, Tenant3 if the version contains “rc”.
So basically we need to combine both the versioning and the multi-tenancy features as I see it. And the tenants have different configuration (but common template), for example Tenant3 might be configured for authenticating towards ADFS etc.
Does it make sense? I’m biased after playing with Octopus for some time, so please tell me if there is a better approach. And please ask if you do not understand - I probably missed some important info…
Thanks for getting in touch! If you haven’t already, I would highly recommend working through the multi-tenant deployment guide where we go into detail on a real-world scenario providing ideas for good practices: docs.octopusdeploy.com/display/OD/Multi-tenant+deployments
Also I would recommend using SemVer 2 for your version numbers, and consider a tool like GitVersion to calculate deterministic version numbers based on commits and branches in your git repository. We use it at Octopus and SemVer, GitFlow/GitHubFlow and GitVersion (using Mainline mode) have simplified all of our branching and versioning concerns: https://gitversion.readthedocs.io/en/latest/why/
I would also recommend looking at our Channels Walkthrough which goes into detail on how to match packages/releases to lifecycles, making sure the promotion paths are secure and safe: https://octopus.com/blog/channels-walkthrough
We are planning to provide better guidance around the build/package/versioning/channels/tenants pipeline but in the meantime you should be able to use the guidance I’ve linked and piece together a really functional pipeline.
The only bit that might be problematic in your suggestion is you would need to rebuild your packages/versions to change the pre-release tag from dev to rc. We use branches and GitFlow at Octopus to help determine the stability of code, and therefore what version tagging to use:
develop branch is for alpha and goes to development environments
feature/whatever branches are for feature development and get their own Tenant and are deployed to the test environment
release/3.4.0 is for stabilising 3.4.0 and gets either beta or rc
master gets full version numbers and is the candidate for release to production.
I forgot to mention, we don’t offer consulting services ourselves, but we have lots of good partners around the world who can help if you need: https://octopus.com/company/partners
We do a lot like you so it seems. For example RC would contain “RC” in the version from TC and “feature/whatever” would also be in the version when it hits Octopus. So I think this should work…
I’ve already been through the guidance you link but I just miss out on how to combine versioning and tenants, but I’ll try.
I’m just tired of learning by doing (if you feel you aren’t laerning anything) so that is why I hoped for some simple “Do this, then do that, etc” recipe
