Build and publish new version of druid core libraries.
Druid FULL Build
Pre-render full site.
Druid partial Build
Pre-render specific routes
Druid FULL Deployment
Deploy full site.
Druid partial Deployment
Deploy specific routes.
Structure:
Category
Workflow(s)
Job(s)
Other Opportunities
We can also automate updates to druids when libs change. When a core lib changes automatically build and redeploy druids using the latest release version of druid core. Same could also be done for micro-frontends and extensions that a druid uses even though they will be separate repos. This would be a powerful automation feature I think.
Considerations:
Automated Testing, Environment Promotion, Security & code scanning, other quality control measures especially with extensions.
Core Libraries
Build and publish new version of druid core libraries.
Consideration: This is dynamic and can be changed but default is to update build repo with new build assets generated by prerender.
It might make sense here to hand off to another flow through committing to separate build repo. The build repo would than take over and manage deployment to the destination. The destination would be configurable but the default destination is aws s3 + cloudfront.
Job: Commit to build repo
Druld partial Build
Build and deployment of single page.
WF: Setup
Job: Checkout Druid Core
Job: Install Node
Job: project dependencies
WF: Configure
Generate environment file, pages static array environment file, and routes.txt file w/ single routes and/or variants using dynamic inputs variables to route.
WF: Prerender
Pre-render Angular application page/specific routes using angular cli
WF: Upload
Consideration: This is dynamic and can be changed but default is to update build repo with new build assets generated by prerender.
Job: Commit to build repo
In this case only pages rendered need to be replaced not the entire application.
Druid FULL Deployment
Static site repo hosting pre-rendered files.
Consideration: Flow files need to be generated from deployment strategy chosen by user on druid cloud / configurable.
WF: Publish to destination ie. s3
Consideration: Each separate destination will be a different workflow ie. aws default (cloudfront + s3), etc.
Job: Create new release directory
Job Upload entire repo contents to new release directory
Job: Update Cloudfront origin to point to new release directory
Job: When cloudfront origin status becomes active again create invalidation /*
Job: When invalidation completes continue...
Druid partial Deployment
Static site repo hosting pre-rendered files.
Consideration: The file hashing might become problematic here since they will different from the original full upload. In that case it might not be possible to replace a single page easily using the same most-recent release directory / destination target.
Consideration: Flow files need to be generated from deployment strategy chosen by user on druid cloud / configurable.
WF: Publish to destination ie. s3
Consideration: Each separate destination will be a different workflow ie. aws default (cloudfront + s3), etc.
Job Upload specific folder to new release directory
Job: When cloudfront origin status becomes active again create invalidation /*
Job: When invalidation completes continue...
AWS login using assume role (preferred). This requires setting up a role with limited permissions and oidc provider.
Run workflow of dedicated runner inside local data center running on 100% renewable energy like Kansas and North Dakota centers.
This will off course affect cost. Could be an option available to the user. Free minutes available on github not so much aws.
The first step in this process will be to establish a connection with aws and push files in a build repo to aws dev environment. To do this will require setup of a role to securely access aws on the runner. We are going to start with using github runners but will probably migrate to using dedicated ec2 instances that are spun up when necessary in regions that run on reneweable energy sources. For now though this needs to kept as simple as possible following the instructions in the aws action to the t to avoid issues.
I wonder if it would be appropriate to make this part of vert-go.
Major security concern with this. Users one shared hosting using trc prod and dev can't be allowed to create roles. They won't be able to create roles as a matter affect. Therefore, the role needs to be provisioned during the deployment setup process or be generesized. For now though lets just get this to work.
Automatic deployment of rtc and ipe through build repos has been wired up for prod / master branch. The current destination is azure static web apps. Azure static web apps has been chosen for cost and obligation to sustainability measures. Not to mention much of Azure is already on running on renewable energy. They are also using offsets.
Next steps will be to add automation of druid core, eliminate workflow duplications, and support partial renderings of pages. Also update spearhead with most recent changes to skeleton changes and automation to druids.
Create github workflows to automate druid flows.
Automation fits into five categories.
Structure:
Other Opportunities
We can also automate updates to druids when libs change. When a core lib changes automatically build and redeploy druids using the latest release version of druid core. Same could also be done for micro-frontends and extensions that a druid uses even though they will be separate repos. This would be a powerful automation feature I think.
Considerations:
Automated Testing, Environment Promotion, Security & code scanning, other quality control measures especially with extensions.
Core Libraries
Build and publish new version of druid core libraries.
WF: Setup
Job: Checkout Druid Core
Job: Install Node
Job: project dependencies
WF: Build
Build libs using matrix.
Job: Builds lib using angular cli
WF: Publish
Publish libs using matrix
Job: Publish lib using angular cli
Druid FULL Build
Build and deployment of complete site.
WF: Setup
Job: Checkout Druid Core
Job: Install Node
Job: project dependencies
WF: Configure
Generate environment file, pages static array environment file, and routes.txt file.
WF: Prerender
Pre-render Angular application using angular cli
WF: Upload
Consideration: This is dynamic and can be changed but default is to update build repo with new build assets generated by prerender.
It might make sense here to hand off to another flow through committing to separate build repo. The build repo would than take over and manage deployment to the destination. The destination would be configurable but the default destination is aws s3 + cloudfront.
Job: Commit to build repo
Druld partial Build
Build and deployment of single page.
WF: Setup
Job: Checkout Druid Core
Job: Install Node
Job: project dependencies
WF: Configure
Generate environment file, pages static array environment file, and routes.txt file w/ single routes and/or variants using dynamic inputs variables to route.
WF: Prerender
Pre-render Angular application page/specific routes using angular cli
WF: Upload
Consideration: This is dynamic and can be changed but default is to update build repo with new build assets generated by prerender.
Job: Commit to build repo
In this case only pages rendered need to be replaced not the entire application.
Druid FULL Deployment
Static site repo hosting pre-rendered files.
Consideration: Flow files need to be generated from deployment strategy chosen by user on druid cloud / configurable.
WF: Publish to destination ie. s3
Consideration: Each separate destination will be a different workflow ie. aws default (cloudfront + s3), etc.
Job: Create new release directory
Job Upload entire repo contents to new release directory
Job: Update Cloudfront origin to point to new release directory
Job: When cloudfront origin status becomes active again create invalidation /*
Job: When invalidation completes continue...
Druid partial Deployment
Static site repo hosting pre-rendered files.
Consideration: The file hashing might become problematic here since they will different from the original full upload. In that case it might not be possible to replace a single page easily using the same most-recent release directory / destination target.
Consideration: Flow files need to be generated from deployment strategy chosen by user on druid cloud / configurable.
WF: Publish to destination ie. s3
Consideration: Each separate destination will be a different workflow ie. aws default (cloudfront + s3), etc.
Job Upload specific folder to new release directory
Job: When cloudfront origin status becomes active again create invalidation /*
Job: When invalidation completes continue...
AWS login using assume role (preferred). This requires setting up a role with limited permissions and oidc provider.
https://github.com/aws-actions/configure-aws-credentials
Sustainability
Run workflow of dedicated runner inside local data center running on 100% renewable energy like Kansas and North Dakota centers.
This will off course affect cost. Could be an option available to the user. Free minutes available on github not so much aws.
The first step in this process will be to establish a connection with aws and push files in a build repo to aws dev environment. To do this will require setup of a role to securely access aws on the runner. We are going to start with using github runners but will probably migrate to using dedicated ec2 instances that are spun up when necessary in regions that run on reneweable energy sources. For now though this needs to kept as simple as possible following the instructions in the aws action to the t to avoid issues.
I wonder if it would be appropriate to make this part of vert-go.
Major security concern with this. Users one shared hosting using trc prod and dev can't be allowed to create roles. They won't be able to create roles as a matter affect. Therefore, the role needs to be provisioned during the deployment setup process or be generesized. For now though lets just get this to work.
Update distribution:
https://gist.github.com/bendrucker/65f340e299ace46a012be2ce97af795f
This has been partially implemented.
Automatic deployment of rtc and ipe through build repos has been wired up for prod / master branch. The current destination is azure static web apps. Azure static web apps has been chosen for cost and obligation to sustainability measures. Not to mention much of Azure is already on running on renewable energy. They are also using offsets.
Next steps will be to add automation of druid core, eliminate workflow duplications, and support partial renderings of pages. Also update spearhead with most recent changes to skeleton changes and automation to druids.