Building an educational game with AI tools and Azure Static Web Apps (Part 2)

In Part 1, we explored how Ren’Py, a visual novel engine built on Python, and AI tools like GitHub Copilot, Azure OpenAI Service, and Microsoft Designer can be used to create a prototype for an educational game. In this post, I will share how I:

• Created a GitHub Actions workflow to automate the build and deployment process for the game.
• Used Azure Static Web Apps preview environments to review changes in the game before deploying them to production.

Curious to see the result? You can play the game online and find the source code at my GitHub repository.

Creating a CI/CD workflow

Manually building and deploying the game with each update can quickly become tedious. Fortunately, Ren’Py includes a CLI tool for automation, and Azure Static Web Apps integrates seamlessly with GitHub Actions, making it possible to automate the entire process.

My goal was to create a simple workflow that would meet the following requirements:

• Automatically build the web version of the game and push it to a separate branch (e.g., the gh-pages branch) for builds triggered by the main branch.
• Deploy the game to the production environment after a successful build from the main branch.
• Provide the option to manually trigger builds and deploy to a preview or production environment from any branch.

Below, I outline the approach I followed. While this is not necessarily the best practice, it serves as documentation for the process I followed, as this was one of my first experiences creating a complete CI/CD workflow. The diagram below provides a high-level overview of the workflow:

1. The source code for the game is stored in the main branch of my GitHub repository.
2. When a new commit is pushed to the main branch, a GitHub Actions workflow is triggered. This workflow builds the web version of the game and deploys it to Azure Static Web Apps.
3. Additionally, the workflow can be triggered manually to build and deploy the game to a preview environment, allowing testing before merging changes into the main branch.

What is Azure Static Web Apps?

Azure Static Web Apps (SWA) is a cloud service designed to simplify the deployment and hosting of modern web applications. A static website consists of pre-rendered HTML, CSS, JavaScript, and media files that don’t require server-side rendering. Azure SWA automates the process of building and deploying the web app by integrating directly with GitHub Actions. Whenever changes are pushed to a monitored branch or a pull request is opened, a new version of the website can be built and deployed.

Azure SWA offers additional, powerful features like Azure Functions integration for APIs, database integration, and support for custom domains that go beyond the scope of this project. You can explore the available features in the Azure SWA documentation.

For this project, the Ren’Py CLI generates a web version of the game, which is then deployed to Azure SWA using the static-web-apps-deploy GitHub Action. Below is an example of the default parameters for this action:

1
2
3
4
5
6
7
8
9

- name: Deploy to Azure Static Web Apps
  uses: Azure/static-web-apps-deploy@v1
  with:
    azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
    repo_token: ${{ secrets.GITHUB_TOKEN }}
    action: "upload"
    app_location: "/"
    api_location: ""
    output_location: "/"

Setting up a preview environment in Azure SWA

Preview environments are an essential feature of Azure Static Web Apps (SWA) that enable you to review changes to your application before pushing them to production. Azure SWA supports three types of preview environment deployments:

1. Pull requests: Each pull request deploys a preview version of your app to a temporary URL. Once the pull request is merged or closed, the temporary environment is removed. If you use the default GitHub Actions template provided by Azure SWA, this process is configured by default.

2. Branch: Changes made to branches other than the production branch can deploy a preview version of the app to a stable URL that includes the branch name. To enable branch preview environments, you can set the production_branch input parameter in the static-web-apps-deploy GitHub Action.

3. Named environment: Named environments allow you to create stable preview deployments with a custom name. These environments are ideal for staging or manual testing. To enable named environments, you need to set the deployment_environment input parameter in the static-web-apps-deploy GitHub Action to the environment’s name.

For this project, I used the named environment feature as it is suitable for manual, controlled deployments. To implement this, I added the deployment_environment input parameter to the deployment task. This parameter is set to the preview environment’s name or left empty for deploying to production.

Bringing it all together

The final GitHub Actions workflow that I created automates the game’s build and deployment processes through the following jobs:

1. Build the game using Ren’Py CLI: The web version of the game is generated using the Ren’Py CLI. The generated files are pushed to the gh-pages branch. If the gh-pages branch does not exist, it is created.

2. Deploy the game to Azure Static Web Apps: The gh-pages branch is deployed to Azure Static Web Apps using the Azure Static Web Apps GitHub Action described in the previous section.

The diagram below provides a high-level overview of the steps executed in the workflow.

There are two possible triggers for the workflow:

1. Automatic trigger on push to main: The workflow is triggered automatically when a new commit is pushed to the main branch. The workflow builds the game and deploys it to the production environment.

2. Manual trigger: The workflow can be triggered manually to build and deploy the game to either a preview or production environment from any branch. The input parameters required include the source branch (containing Ren’Py game files), target branch (for generated files), and environment name.

Summary

In this post, I described the steps I took to create a GitHub Actions workflow for automating the build and deployment of a Ren’Py game to Azure Static Web Apps. I also showed how preview environments can be used to test changes before they are deployed to production.

If you’re interested in learning more about Azure Static Web Apps or GitHub Actions, check out the following courses on Microsoft Learn:

• Azure Static Web Apps
• Automate your workflow with GitHub Actions