So I have a question about stacks. What’s conside...
# getting-started
s
So I have a question about stacks. What’s considered best practice for creating developer sandboxes? Our company is doing some work that involves event grid topics, subscriptions, queues, and some other resources that will not be shared across devs. Is it common practice to create one stack per developer? What about checking those into stack definitions into source control?
v
sounds a bit wild to have a stack per dev. we use stacks like 'environments' here, so we have a stack in each aws account (environment) and one of those is sandbox where devs have access to everything then above sandbox its governed access
we use aws sso users and groups to achieve the permissions
s
But for the ‘dev’ stack, what if you wanted each developer to have their own instance of it without trampling over each other’s work?
Think of it akin to having the cloud equivalent of a local setup. If this was all stuff that could run in containers, we’d just use docker compose and the like
v
we have 3 dev environments, so if the actual infra needs to be deployed then theres multiple places to try it - however we do see issues with contention atm and are looking at ephemeral environments
some people use localstack for local dev against aws services but i havent used it recently
s
We’re unfortunately pretty locked into azure. What we ended up doing is creating a ‘local’ stack per dev but we’re not committing those to source control. The state gets persisted elsewhere so in the event of a local disk crash, you can still destroy orphaned stacks.
v
ah fair enough, yeah we have plenty of stacks in our sandbox account that dont have any code in git, just from messing around locally. it can get messy pretty quick though so i tend to do a clean up once a month of stacks we dont need anymore