Lab
A Cloud Guru

Deploying a Static Site with GitHub Actions

You are working for a consumer software company that is preparing to announce a major new product. You have been tasked with setting up the landing page for users to learn more and sign up for the beta. Marketing has approved an initial static JavaScript page, but this page will need to be able to update quickly as news breaks. You will need to set up a GitHub Actions workflow to build and deploy the site to a non-Production bucket, and then promote it to a Production bucket once Marketing has approved the new design.

Try for free Contact sales

Path Info

Level

Intermediate

Duration

1h 0m

Published

Sep 24, 2021

Challenge

Set Up Secrets in GitHub
1. In the lab AWS account, note the names of the s3 buckets. One will begin nonprod and the other will begin prod. Also note the AWS account ID. We will need these details later in the lab.
2. Create a github_user IAM user and assign it S3FullAccess. Note the access key and secret key.
3. Fork the GitHub Repo to your personal GitHub. This is important since you cannot make changes to the lab repo.
4. In your forked repo, under Settings, scroll down to Secrets. Create new repository secrets for AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_ACCOUNT_ID.
Challenge

Set Up a Non-Production Workflow
1. Clone the code, either locally or to a Cloud 9 instance. Create a new branch: feature-initial-page.
2. Create this file: ./github/workflows/nonproduction.yaml
3. Set up the trigger code.
4. Set up a job to configure AWS credentials.
5. Set up a job to install Gatsby.
6. Set up a job to build the site.
7. Set up job to upload to the non-Production S3 bucket.
8. Set up a variable name for the bucket.
9. Push the code and monitor its execution in GitHub.
10. Check the non-Production site URL to see if the site deployed.
Challenge

Set Up a Production Workflow
1. Open the code, still on the feature-initial-page branch.
2. Create this file: ./github/workflows/production.yaml.
3. Copy the content from ./github/workflows/nonproduction.yaml, modify the trigger code, and replace the variable for the bucket with the Prod bucket.
4. Push the code. Note the non-Production workflow runs since this is a feature branch, not an approved PR to main.
5. Create a PR to main and approve it. This is where you can control approvers so that only code that has be vetted goes to Production.
6. Monitor the execution of the Production workflow.
7. Check the Production site URL to see if the site deployed.
8. Create a new branch from main called feature-launch-date.
9. Add HTML to index.js with the product launch date.
10. Push the code and monitor the execution of the non-Production workflow.
11. Check the non-Production site and see if new information deployed.
12. Open a PR and approve it.
13. Monitor the execution of the Production workflow.
14. Check the Production site URL to see if new information deployed to Production for users.

Author

A Cloud Guru

The Cloud Content team comprises subject matter experts hyper focused on services offered by the leading cloud vendors (AWS, GCP, and Azure), as well as cloud-related technologies such as Linux and DevOps. The team is thrilled to share their knowledge to help you build modern tech solutions from the ground up, secure and optimize your environments, and so much more!

What's a lab?

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.