-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
canary/phased releass #53
Comments
Hey, something I want to look into as part of this and as part of cdkpatterns.com is to integrate this construct with the new dev preview of cdk pipelines (https://docs.aws.amazon.com/cdk/api/latest/docs/pipelines-readme.html). I agree with you that a documented blue/green deployment process is needed |
The CDK is moving to distributions and this library is going need to be refactored. |
Hey @FavorWedge can you elaborate a little on your comment? |
@nideveloper with the introduction of lambda@edge AWS is refactoring the CloudFront stack. Once this new format is stable I can help refactor to support.
|
Hi there! First of all, thanks for the work, I think it's a great initiative to have a simple and universal way to deploy SPAs.
Reading the code I don't see anything related to having some sort of control over the release quality, that is, the construct simply puts files on a S3 folder. For services – both ec2 or lambda – there are a bunch of strategies built in the CodeDeploy lib (here) that can automatically check the health of the new instances and decide how to proceed.
Have you considered some way of validating the quality of the SPA releases (even if this is decoupled from the main deployment construct), perhaps monitoring JS errors?
The text was updated successfully, but these errors were encountered: