Configure your deployment environment in GitHub
Now that we’ve built and tested our application with GitHub Actions, it’s almost time to deploy it. But first, we should create and configure a deployment environment. Environments not only allow us to target deployments to different environments for different reasons, they also provide a single location to view information about those deployments. And TELUS will join us to offer their expertise on setting up deployment environments effectively.
In this guide, you will learn:
How to create a new deployment environment
Best practices for configuring deployment environments
Create your deployment environment
1. Return to your actions-learning-pathway repository and click Settings. If you cannot see the "Settings" tab, select the … dropdown menu, then click Settings.
2. In the left sidebar, click Environments.
3. Click New environment.
Deployment environments are commonly named development, staging, or production to identify where they fit into the software delivery lifecycle. We’ll keep it simple for now, and name our environment production.
4. Enter “production” for the name, then click Configure environment.
Ensuring smooth deployments hinges on an organization's ability to balance simplicity and strategic customization. We recommend setting up a core, two-environment framework—a non-production environment for development and testing, and a production environment for end users—to minimize confusion and configuration overhead. Then, when you need to introduce experimental features or refine existing ones, just add a staging environment where you can test, fix bugs, and know everything is working properly before deploying to production.
Configure your deployment environment
Beyond offering a clearly defined deployment target, environments also provide a variety of settings to help safeguard them. For example, you can restrict which branches or tags can be deployed to an environment, store environment-specific variables and secrets, and enforce protection rules, such as requiring specific people or teams to review workflow runs before deployment.
We’ll leave these to their default for now, but familiarize yourself while you’re here. We explore them in more detail in a later guide on automated deployment protection rules in Actions.
Use environmental variables to cut down on manual configuration edits. You can use variables to represent all sorts of non-sensitive information about your environment, such as file paths, operating system versions, and more. When these details change, you only need to update the variable, saving you the work of updating each individual file. It also makes it easier to run code and workflows in different environments.
For more sensitive information, use Actions secrets. Think of putting a password in a workflow or configuration as the equivalent of writing your password on a sticky-note on your monitor. Actions secrets provides a secure way to manage authentication tokens and other secrets across environments.
Turn on GitHub Pages
Before we move on to deployment, we have one more quick task to take care of: turning on GitHub Pages, which we’ll use as our deployment target.
Return to your actions-learning-pathway repository and click Settings under your repository name. If you cannot see the Settings tab, select the “…” dropdown menu, then click Settings.
Click the Pages tab.
Under Build and deployment select the Source dropdown. Choose "GitHub Actions".
Up next: Automating and deploying workflows with GitHub Actions
Now that our deployment environment is configured, we can move on to the fun part: deploying our application to GitHub Pages. Join us in the next guide to learn best practices for successful deployments.