Pipeline stack for CI/CD

[chriswilty]

Use CDK to define a CodePipeline for building, testing and deploying stack resources.
https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html

Notes

• Merge to main branch will trigger pipeline deployment of "prod" stage
• CDK Pipelines are self-updating, after initial manual deployment 🏆
• Pipeline synthesizes and deploys all other (application) stacks

Concerns

Currently the individual stacks are not tested, so it is possible that stack synthesis or deployment could fail when the pipeline runs. We could at least trigger synth as part of the github cloud workflow, even if we do nothing with the output, but better would be to write construct tests.

Acceptance Criteria

• Prod-stage pipeline can be synthesized locally and deployed to our SpyLogic AWS account
• Pipeline is triggered on merge to main branch
• Upon successful completion of pipeline run, new version of application is deployed to spylogic.ai

[chriswilty]

As I am being moved off the project, I am deprioritising this stack in favour of the Route53 / domain setup with authentication. My notes so far:

• Newer CDK Pipelines looked promising until I realised there is no obvious way to deploy the UI as part of the pipeline, unlike with the original Code Pipelines API which has a dedicated S3Deploy action.
• Might be possible using BucketDeployment, although the cache Invalidation is still a problem to solve, as is providing the necessary IAM policies.
• Might be possible using a dedicated CodeBuild action; can that be added to a Stack, and then triggered from the pipeline?

[chriswilty]

Update

I was able to get the pipeline working with the new CDK Pipelines API. I used a custom Step (see cloud/lib/constructs/DeployS3Step.ts) for deploying the built UI to the host bucket, and a CodeBuildStep (which can be configured with IAM access policies) to invalidate the CloudFront distribution cache.

Tested by deploying a dev stage pipeline. The pipeline auto-runs when first deployed, but in testing I used the cloud infrastructure feature branch as the pipeline trigger. Once teething problems had been ironed out and the pipeline succeeded, I was able to validate the deployed application at dev.spylogic.ai. I did not create a new SSO application in Azure, but adding a user to the dev UserPool allowed me to log in and interact with ScottBrewBot as expected.

This dev stage was subsequently destroyed so is no longer available, however, the templates allow deploying a pipeline for any named stage, and upon pipeline completion the UI will be available at https://{stagename}.spylogic.ai, with the API available at https://{stagename}.spyogic.ai/api.

[chriswilty]

NOTE: Upon merge into main, I will synth the pipeline and deploy. However, I will first need to destroy the existing prod stacks as the pipeline will not recognise them as its own, so would fail with duplicate resource errors. It will mean a short downtime, so I will likely do this first thing in the morning.