I’m currently working on designing a Tenanted Deployment Project.
The project will involve for example doing a Database upgrade for specific client. The problem is that the client might have 70 Database running the exact same software that will need to be upgraded.
Currently clients are Managed by making them a Tenant and then a Project would run through upgrading 1 Database.
How can change the design so I’m able to target a group of Databases for a specific Tenant?
One other note is that we have 1 tentacle running at a client that is able to target all the Databases.
Thanks for getting in touch! I have had a chat with the team about available options to address your scenario and currently we don’t have any great solutions.
Our discussion settled on a couple of ideas. One which involved manually defining the databases via Tenanted variables each release. To us, this is not a great Automated solution over 70+ databases.
The other idea we considered was using another database on the target to decide which databases were to be upgraded. This would still suffer from the same issues as the above suggestion.
It may help us to have some more information about your requirements and thoughts on what you would like Octopus to be able to do here.
How would you like to see Octopus handle this sort of scenario?
Would manually selecting each database you wish to upgrade at the time of deployment be an option for you?
The above questions will give us a better idea of how we can help you design this.
Currently running the Project for each instance of the Database is not ideal so any suggestion to improve that will be helpful.
To give you a bit more information on how we would like to see it run.
Clients are currently run as Tenants and then have Environments/Lifecycles called UAT and Production. We would first upgrade a clients’ UAT environment and after UAT testing is completed we upgrade Production. A clients’ Production environment would have a Database for each shop that they own. So a client might have 70+ shops.
We would ideally like to upgrade their Production environment in Groups. So first a Pilot site (1 Database) then maybe groups of 5 to 10 sites at a time.
One other thing I was thinking of was to register multiple instances of the tentacle on the same server that will run the upgrades against the Database. Maybe 20 or so Tentacle instances per server and each instance represents a Database. Then split the tentacles into environments for example Pilot, Group 1, Group 2 etc.
Would that work?
The only issue might be how do I change the Database name during each run of the Instance.
Thanks for getting back here. We have a few ideas on how you can model this in Octopus. I think the most clear cut solution we have is to create a Tenant for each “Shop” and use Tenant Tags to group them. This approach will give you the finest control over which databases are deployed at any given time. However, it will create a separate task for each Tenant/Shop.
Another option which may work for you is to step through the master database and retrieve a set number of shops, execute the database upgrade, then use something like a manual intervention step to pause the deployment while the upgrade is tested. This method would require duplicating the steps in your deployment and breaking them up with Manual Intervention steps. Using this approach, you can upgrade the databases at any pace you desire. It will require some custom scripting to loop through the master database and return the information back to Octopus.
The following blog post has some helpful information on looping through the database to deploy with Octopus.
Do these options help?
Let me know if you have any further thoughts or questions here, or if these options do not helps.