I have created an “abstract parametrized archetype stack” of a SaaS project in SLS Framework. All you have to do is to run sls deploy --stage prod --tenant abc --param1 something --param2 otherthing and it creates its own, totally separate stack with the app. I will be the one creating, maintaining, updating, patching and removing multiple stacks(customers) and I am looking for a good way to do so.
Now, when I worked with Terraform, the repository containing such an archetype (a Terraform module) would be versioned (with git tags) and other projects would use it by pointing at that repository and specifying a version(module "my_app" { source = "git::https://example.com/archetype.git?ref=v1.2.3" }. Then I could maintain the archetype and release new versions with new features without affecting any project using it. If anybody wants to upgrade, they would just bump the version in their .tf file and perform the upgrade on their own. I had a repository with multiple customer_a.tf, customer_b.tf and so on, all pointing at the archetype with their own version and configuration.
How to achieve similar stuff with SLS? What are your practices?
Metaphorically speaking, is there a way to have repository with multiple directories /customer_a/serverless.yml, /customer_b/serverless.yml containing (pseudocode and metaphor - this could work totally different - but I’m sure it pictures what I want to achieve):
source: git://whatever/abstract.sls?ref=1.2.3
params:
stage: dev
param1: customer_a
param2: otherthing
and I’d just use sls deploy in that directory to maintain given customer and maybe tweak some params or bump a version.
This is necessary for me as I am working in a team, so a knowledge “which tenant has which version with what parameters” is crucial. I also would love not to copy code at all. The pattern above(repository with multiple files) comes from my Terraform(and Terragrunt) experience.