We use `app/microservice/environment` style as fol...
# general
p
We use
app/microservice/environment
style as follows:
Copy code
├── app1
│   ├── api
│   │   ├── dev
│   │   ├── prod
│   │   └── qa
│   └── webapp
│       ├── dev
│       ├── prod
│       └── qa
└── app2
    ├── api
    │   ├── dev
    │   ├── prod
    │   └── qa
    └── webapp
        ├── dev
        ├── prod
        └── qa
When using s3 as a backend, what should I use when creating a new project (ie, project name and stack name) and how do I actually access the output from a different app? I assume the stack name is just "dev", "prod" or "qa". What about project name?
l
The project name is unimportant in the decision: go with something informative. app1, app2 is probably good enough. Or if you want to deploy apps together, you might use a single apps project. You'll almost certainly need one or more base projects that the app projects depend on, to set up things like DNS, VPCs, VPC endpoints, maybe shared DBs and/or LBs, and more.
I believe that the stack name, unfortunately, needs to echo the project name in some way. This may not be true any more, I know there have been improvements in this area; check the docs to be sure. But until last year at least, you needed to discriminate between app1's dev stack, and app2's dev stack. So, app1_dev and app2_dev would be appropriate.
To access outputs of one stack in another stack, you use stack references. The docs and examples are good. https://www.pulumi.com/docs/concepts/stack/#stackreferences
p
Coo, cheers. The
app1_dev
app2_dev
is what I really dislike... But I guess I just chuck all services belonging to an app in the same project and be done with it
l
Leave the underscore out? 🙂 app1Dev, app2Dev...
It's just a string. Set up string constants somewhere and ignore the actual strings 🙂
p
Yes but... If you know you know... Haha... My OCD would forever be unbalanced 🙂