13_GitHub Actions' Internal AWS Workflows
Flox makes use of GitHub actions to automate as much of the deployment process as possible. This page covers the different actions in detail.
This workflow sets up the initial infrastructure for a new Flox project on AWS. Therefore, it should only be run once per mode. If you run the workflow again on an existing system, existing infrastructure (such as user pools or databases) may be destroyed permanently. Thus, there is no automated workflow that triggers this step. Here you can see the full workflow:
Let's have a look at each step in detail.
First, the flox.tfvars Terraform variable file is created based on the configurations from the flox.config.json files from both frontend and backend. This file will be used for the various Terraform runs. A first run sets up Cognito and the hosted zone and its output are added to the flox.tfvars file. With this new data, the .env file for the frontend application is created as well.
This step is only executed in either dev or test mode. Essentially, it allocates the project's subdomain to the customer account from within the Polygonsoftware AWS account, which owns the polygon-project.ch domain. The subdomain is structured as follows: <mode>.<project>.polygon-project.ch. E.g. in test mode, the subdomain would be test.flox.polygon-project.ch.
Therefore, the customer account can now freely make use of this subdomain to host its test/dev-systems.
The default subdomain used by the backend is api.<mode>.<project>.polygon-project.ch, e.g. api.test.flox.polygon-project.ch.
In this step, the actual application is built and deployed. In a first part, both frontend and backend are built as either a serverless or regular application. Then, if the frontend is a non-SSR application (thus either PWA or SPA), its files are unzipped for direct S3 upload. Lastly, the main Terraform run is executed and the infrastructure for both frontend and backend is deployed.
This step is only applied the action is run in local mode. All built files are deleted and any removed node modules are quietly reinstalled.
This action is responsible for updating an existing AWS infrastructure, without creating everything again from scratch. Thus, only the code is changed, while the infrastructure remains. When running just the update workflow, changes to the infrastructure configuration inside flox.config.json will have no effect. Again, the full workflow is displayed here:
This step prepares all the parameters needed for the update. First, the flox.tfvars Terraform variable file is created from the flox.config.json files. Then, a pre-update Terraform run is executed to get the SSM parameters as well as, if applicable, remove the previous version's statically hosted files from S3. The gathered SSM parameters are then written into the flox.tfvars file.
In this step, building first, the .env file for the frontend is created. The application is built for either serverless or regular deployment. Then, if the frontend is a non-SSR application, its files are unzipped for direct S3 upload. Lastly, the main Terraform run is executed and the update files are deployed. While the source code has been updated in this step, the application itself may still be running an older code version.
This steps handles redeploying the relevant resources, based on the application's type. non-SSR apps also apply a cache-invalidation on the Cloudfront distribution, so the newest frontend version will be served. Serverless API applications update renew Lambda as well.
This step is only applied the action is run in local mode. All built files are deleted and any removed node modules are quietly reinstalled.