hi, not sure if this is the correct channel for th...
# pulumi-cloud
r
hi, not sure if this is the correct channel for this question. but im currently working in a team working on the same pulumi project. each team member has a fork and when they run a deployment using
pulumi up
the other team member has to redeploy the entire stack again. thinking its a state issue, but state is managed via the pulumi backend. and, interestingly -> when a specific member of my team deploys, pulumi changes the VCS link on that stack to the forked repo and not the original repo. could i any help on this? this significantly affects development time.
b
How are you using stacks? In this configuration, each member should have their own stack and you should converge on a “production” stack that is corresponds to your main branch
Are developers deploying changes against the same stack? That would explain the behaviour
r
yes, they are deploying against the same stack
b
Okay that sounds like the issue
r
are you suggesting one developer have a single stack?
person-a-stack-1
person-b-stack2
but wouldnt that duplicate the resources?
for instance, if we are working on the same microservice, id have x number of stacks for the same microservice for x number of devs?
what do you suggest @billowy-army-68599
b
Yes it would duplicate resources. Generally the pattern is: Use a personal stack to do development which is torn down when the development is complete. You merge that code into a branch that tracks the actual development or production environment
r
but what if it uses something like route 53 and etc in that stack? then generally whats the practise?
l
That should also be stack/developer-specific. Just change the base domain for each stack. A common pattern is to prepend the stack name to all domains, except for the production one. For example, if your product uses myproduct.info as your main domain, and if you have stacks per developer, then you might have lakinduh.myproduct.info, tenwit.myproduct.info, etc. Then your normal Pulumi app logic will may things like www.lakinduh.myproduct.info, db.lakinduh.myproduct.info, etc.
Any "shared" stack should be deployed mostly from a pipeline, based on merged PRs or similar. This would include things like prod, staging, europe1, e2e, and so on.
r
ohh i got you
and these subdomains can be protected for specific IPs and etc