Hi, Would anybody know of a documentation that co...
# guide
m
Hi, Would anybody know of a documentation that covers usage of SST in projects with CICD pipelines that may require a manual test+approval action before a production deploy? Any hint for "blue/green" deployment strategy with SST? I was wondering how to best approach deployments of "Api" or "StaticSite" constructs, so that applications are partly deployed to an environment but are awaiting a final confirmation from QA teams before the Route53 zone record is finally updated to point to actual distribution of API Gateway or CloudFront, respectively.
g
Using seed we just do a staging environment and then manually promote to production we do nothing special blue/green is automatic since it's all serverless.
f
Hey @Matt Bulwan, a couple of things on top of my head I’d want to throw it out there: 1. You can create a Custom Resource that waits for the confirmation, and have the Route53 record depend on the CR. CR has a max timeout of 1 or 2 hrs (i think), and CR fails if the confirmation is not received within that time. 2. Or you can move the Route53 to its own stack. And deploy all but this stack. And on confirmation, deploy the Route53 record stack. I’m sure there are more/better ways to do this 😁
m
thank you, both Garret and Frank. I like the "2... move Route53 to its own stack". I guess to get it implemented, the "Api" construct would still need some provisional:
Copy code
new sst.Api(
    customDomain: {
        domainName: "${stage_name}.<http://example.com|example.com>
      },
}
and then the separate Route53 stack would need to create either an alias 'api.example.com=>$[stage.example.com}' or update it in a different way?
f
Yeah, we’d need to do some work to make 2 to work. Probably add an option in
Api
to skip creating the Route53 record.
What’s your timeline on needing this?
m
Hi Frank, no strict deadline, the project won't go live for another 7-8 weeks anyway. I am not even sure it the Route52 switchover would work (ACM certificate for example could be failing) and perhaps there are other ways. I am essentially trying to find any "blue/green" (conceptually) approach to have parallel deploys of (Api Gateways + Lambdas) versions of the application and switch them AllAtOnce upon. At the moment I am just exploring whether SST high level constructs support features like Lambda version update (->$LATEST) or AWS API Gateway stages to facilitate any AllAtOnce switchover scenario. I'll yet need to take a look at how SEED does that.
f
Gotcha 👌