Hi Folks. I’ve just started working with SST at our company. I’m quite a fan of CDK and this is looking very nice. Would anyone be able to guide me to best practices for working with mid size dev teams 8-12. How do we avoid constantly stepping on each other when working locally? Won’t’ we be deploying the same stack over each other? I have multiple accounts per environment. But if I try to create multiple accounts per developer, my infra costs would be massive. Some of my resources are EC2 instances. Any ideas would be wonderful.

Each developer deploys their own stage So for example all my resources would be under

dax-myapp-mystack

Hey @Nathan I am solving the same problem at my company. We have approximately 80 engineers that work on different domains using a variety of technologies. I'm slowly but surely introducing SST into the org. Here are a few lessons learned: • As @thdxr mentioned, you'll want each developer to deploy to a different stage so they don't step on one another. For example, from my package.json

"scripts": {
    "start": "sst start --stage $(whoami) --profile=<SSO profile for the shared development account>",...

• In the case of a non-serverless instance based resource (e.g. RDS, OpenSearch, etc), I create a single instance of the resource that is shared across all development environments. I do this by using conditionals in my infrastructure as code that utilizes a shred instance when running locally, but create the resource otherwise. For example, from one of my stacks that creates an RDS database:

export function DbStack({ stack, app }: sst.StackContext) {
  if (app.local) {
    // import shared RDS instance here
    const db = rds.DatabaseInstance.fromDatabaseInstanceAttributes(...)
    return {db}
  } 

  // create RDS instance here
  const db = new rds.DatabaseInstance(...)
  return {db}
}

Note that this will mean you need to deploy the shared instance first so it exists for everyone elses development environment. I do this by deploying the single stack to a

shared

stage:

yarn run sst deploy DbStack --stage=shared --profile=<my sso profile>

• I haven't yet solved the problem for EC2 deployments, but I'll need to very soon. My current idea is to treat it the very same way I treat AWS Lambda in development. That is, the compute resource runs locally, but everything else (DB's, queues, etc) runs in the cloud. I'm not sure what that looks like in practice yet, but that's where I'm going to start

exactly what I was thinking but better said haha. Fwiw you don't need to pass --stage=whoami anymore, on first run SST will generate a name for you based on your AWS credentials and prompt you to override

Yeah, I thought about removing that from the package.json. Ultimately, I left it in place because I think it'll be easier to onboard new engineers that don't know anything about SST (or shared AWS environments for that matter). I want to avoid having a developer choosing

dev

as their stage name 🙂

yeah fair

It's just a guardrail for now

@Seth Geoghegan @thdxr Wow! Thanks to both of you. I honestly didn’t expect to even get an answer for a while. This is excellent and a great place for me to start. @Seth Geoghegan I am doing the same as you, integrating slowly. So I’ve got some room to play while I figure this out.

this is a great community 🙂

Thank you all, great stuff, really useful!!

@John Kinsella ^ when we eventually get around to it this will be a useful thread to use

What is the best practice for making sure s3 and databases are removed when debugging? I run into the error that the resources already exists when i run ‘sst start’, then next time i have to delete them manually from the console before trying to run ‘sst start’ again.

Set the removal policy for the resource to DESTROY when you're running in development