Thanks for keeping in touch! I think it would be nice if we could hook up on a screen share and go through your scenario in more depth.
Can you book a time that suits you so we can work through this together?
In the meantime, packages and lifecycles are both treated as shared resources and don’t participate in “scoped permissions” (restrictions via environment, tenant, project). We are currently working on a project called Spaces, which may be a good fit since each Space is essentially a fully secure sandbox, but it may also be too heavy-handed.
I’ve emailed an invitation to comment on that working document.
Suggestion: Library Variable Set per Tenant
As I mentioned, I think you’ll have a better experience while you are still using Library Variable Sets, to use each set as a sandbox. There are some downsides (needing multiple sets, and scoping each variable manually) but you should get the isolation you’re hoping for.
Suggestion: Make each developer/tester a Tenant
A core tenet of Octopus is to make your deployments as consistent as possible across your environments. In this case I’d recommend modelling any of your “sandboxes” in the same was as you do for Production. When each developer/tester becomes a tenant, you’ll be exercising the self-same deployment strategy across all your environments. Plus you’ll have the dashboard telling you the truth about your sandboxes, and make it harder to pave over someone else’s sandbox. Plus you won’t have to use the “Include Specific Machines” workaround you showed me.
Can you take a backup of your SQL Server database for Octopus, zip it and upload it to the location in the email I’ve sent?