@keyboard-logic/terraform-test-fos v1.5.5

= Deployment POC

Sample Front End project to demonstrate deployment.

== Deployment

=== Widget

The widget is a publicly available javascript bundle to allow embedding the click to call widget on the customer's website.

In order for customer's to embed the javascript on their website, the widget will be deployed to a Content Delivery Network (CDN). In this case, we will use CloudFront + S3 as our CDN. The widget bundle will be deployed as a modern javascript bundle in UMD format. This will allow the customer's to include a single script tag in their website to include all the necessary javascript to initialize and show the widget.

Vite will be used in library mode to create the widget bundle.

To deploy or publish the widget, semantic-release will be used to publish the build artifacts to our private npm registry. Afterwards, during the "deploy" step of the CI/CD pipeline, the artifacts (including the javascript bundle) will be uploaded to the provisioned S3 bucket.

==== Versioning

In order to allow multiple versions of the widget to be deployed, S3 paths/prefixes will be used. That is, when a new version is released, the artifacts of that release will be uploaded to the S3 bucket as /. e.g. 1.2.4/main.js.

Along with the version specific path, an additional path may be uploaded depending on the current branch that is being deployed.

If deploying on the master branch, the LATEST path prefix will be updated and a cloudfront invalidation created for /LATEST/*. This allows customers to refer to the most recent version at https://<url>/LATEST/main.js.

In addition to the LATEST tag, a major version path will also be uploaded and invalidated. For example, if releasing on the master branch with version 2.5.1, a 2.x path will be uploaded and a /2.x/* cloudfront invalidation will be created.

==== Maintenance Branches

Version specific maintenance branches may be used to support older, deprecated, versions of the widget for security fixes and/or bug fixes.

To do so, additional major version specific branches can be created in the repository. e.g. 1.x, 2.x, 3.x, etc.

When performing a release on a version branch, the actual version path will be created along with updating and invalidating that specific version path. For example, if releasing on the 2.x branch with version 2.5.1, a 2.x path will be uploaded and a /2.x/* cloudfront invalidation will be created.

== Backend

The backend is the APIs built to support the publicly facing widget along with the customer UI.

As the APIs support the public widget, they must strive to be built in a backwards compatible way. That is, when APIs are updated, only new properties are added. Removal of existing properties will not be allowed on existing, in-use APIs.

If a backwards incompatible change is required, a new version of that API must be created and exposed as a new version. e.g. /api/v1/ vs /api/v2/. This will allow backwards incompatible changes to be added to an API.

Old versions of the APIs must be supported until sunset. Sunset timelines and communications to customers regarding sunsetting of APIs will be determined in the future as the need arises.