square-car-84996
10/21/2021, 6:40 PMbillowy-army-68599
10/21/2021, 6:49 PMPulumi.stackname.yaml
- there should be one of those for every stack you have, and you should check that into your version controlsquare-car-84996
10/21/2021, 6:53 PMsteep-toddler-94095
10/21/2021, 8:15 PMyes, but isn't the best way to version things between stacks by using branches?Not necessarily. For example, you might have persistent dev, staging, and production EKS clusters. In that case you might want to have 3 Pulumi stacks for a single Project, with the
main
branch as your source of truth. If you want to test changes against only dev
you can modify your code/configuration in a way that only impacts dev on a pulumi up
square-car-84996
10/21/2021, 8:41 PMsteep-toddler-94095
10/21/2021, 9:26 PMsquare-car-84996
10/21/2021, 9:31 PMsteep-toddler-94095
10/21/2021, 10:15 PMdev
as the default branch. Any new features are first merged into dev
. You can reference the helm chart by path rather than a version specification (so you don't need to worry about updating a version number - the code on the persistent git branch will be a full description of your infra). Marge into dev
kicks off a deploy and test. If things are good then PR from dev -> test
. If things are good after merge then PR from test -> prod
. What do you think?billowy-army-68599
10/21/2021, 10:23 PMpulumi up -c chartVersion 1.0
square-car-84996
10/21/2021, 10:38 PMsteep-toddler-94095
10/21/2021, 10:44 PMenvironment
value, which I use to choose the "actual" config in code. This allows me to do much more, like statically-type my config and pull values from other code or non-code files. though if you won't benefit from those things then no need to do thissquare-car-84996
10/21/2021, 10:55 PMsteep-toddler-94095
10/21/2021, 11:47 PM