Create two deployment workflows using GitHub Actions and Microsoft Azure.
- Who is this for: Developers, DevOps Engineers, new GitHub users, students, and teams.
- What you'll learn: We'll learn how to create a workflow that enables Continuous Delivery using GitHub Actions and Microsoft Azure.
- What you'll build: We will create two deployment workflows - the first workflow to deploy to staging based on a label and the second workflow to deploy to production based on merging to main.
- Prerequisites: Before you start, you should be familiar with GitHub, GitHub Actions, and Continuous Integration with GitHub Actions.
- How long: This course is 6 steps long and takes less than 2 hours to complete.
- Above these instructions, right-click Use this template and open the link in a new tab.
- In the new tab, follow the prompts to create a new repository.
- For owner, choose your personal account or an organization to host the repository.
- We recommend creating a public repository—private repositories will use Actions minutes.
- After your new repository is created, wait about 20 seconds, then refresh the page. Follow the step-by-step instructions in the new repository's README.
A lot of things go into delivering "continuously". These things can range from culture and behavior to specific automation. In this exercise, we're going to focus on the deployment part of our automation.
In a GitHub Actions workflow, the on
step defines what causes the workflow to run. In this case, we want the workflow to run different tasks when specific labels are applied to a pull request.
We'll use labels as triggers for multiple tasks:
- When someone applies a "spin up environment" label to a pull request, that'll tell GitHub Actions that we'd like to set up our resources on an Azure environment.
- When someone applies a "stage" label to a pull request, that'll be our indicator that we'd like to deploy our application to a staging environment.
- When someone applies a "destroy environment" label to a pull request, we'll tear down any resources that are running on our Azure account.
At the start of each workflow run, GitHub automatically creates a unique GITHUB_TOKEN
secret to use in your workflow. We need to make sure this token has the permissions required for this course.
- Open a new browser tab, and work on the steps in your second tab while you read the instructions in this tab.
- Ensure that the
GITHUB_TOKEN
for this repository has Allow GitHub Actions to create and approve pull requests enabled under Workflow permissions. Learn how. This will allow GitHub Actions to merge pull requests as you move through the steps in this course. - Ensure that the
GITHUB_TOKEN
also has Read and write permissions enabled under Workflow permissions. This is required for your workflow to be able to upload your image to the container registry.
For now, we'll focus on staging. We'll spin up and destroy our environment in a later step.
- Go to the Actions tab.
- Click New workflow
- Search for "simple workflow" and click Configure
- Name your workflow
deploy-staging.yml
- Edit the contents of this file and remove all triggers and jobs.
- Edit the contents of the file to add a conditional that filters the
build
job when there is a label present called stage. Your resulting file should look like this:name: Stage the app on: pull_request: types: [labeled] jobs: build: runs-on: ubuntu-latest if: contains(github.event.pull_request.labels.*.name, 'stage')
- Click Start commit, and choose to make a new branch named
staging-workflow
. - Click Propose a new file.
- Click Create pull request.
Note: Wait about 20 seconds then refresh this page for GitHub Actions to run before continuing to the next step.
We won't be going into detail on the steps of this workflow, but it would be a good idea to become familiar with the actions we're using. They are:
actions/checkout
actions/upload-artifact
actions/download-artifact
docker/login-action
docker/build-push-action
azure/login
azure/webapps-deploy
- In a new tab, create an Azure account if you don't already have one. If your Azure account is created through work, you may encounter issues accessing the necessary resources -- we recommend creating a new account for personal use and for this course.
Note: You may need a credit card to create an Azure account. If you're a student, you may also be able to take advantage of the Student Developer Pack for access to Azure. If you'd like to continue with the course without an Azure account, Skills will still respond, but none of the deployments will work.
- Create a new subscription in the Azure Portal.
Note: your subscription must be configured "Pay as you go" which will require you to enter billing information. This course will only use a few minutes from your free plan, but Azure requires the billing information.
- Install Azure CLI on your machine.
- In your terminal, run:
az login
- Copy the value of the
id:
field to a safe place. We'll call thisAZURE_SUBSCRIPTION_ID
. Here's an example of what it looks like:[ { "cloudName": "AzureCloud", "id": "f****a09-****-4d1c-98**-f**********c", # <-- Copy this id field "isDefault": true, "name": "some-subscription-name", "state": "Enabled", "tenantId": "********-a**c-44**-**25-62*******61", "user": { "name": "mdavis******@*********.com", "type": "user" } } ]
- In your terminal, run the command below.
az ad sp create-for-rbac --name "GitHub-Actions" --role contributor \ --scopes /subscriptions/{subscription-id} \ --sdk-auth # Replace {subscription-id} with the same id stored in AZURE_SUBSCRIPTION_ID.
Note: The
\
character works as a line break on Unix based systems. If you are on a Windows based system the\
character will cause this command to fail. Place this command on a single line if you are using Windows.**
- Copy the entire contents of the command's response, we'll call this
AZURE_CREDENTIALS
. Here's an example of what it looks like:{ "clientId": "<GUID>", "clientSecret": "<GUID>", "subscriptionId": "<GUID>", "tenantId": "<GUID>", (...) }
- Back on GitHub, click on this repository's Secrets in the Settings tab.
- Click New secret
- Name your new secret AZURE_SUBSCRIPTION_ID and paste the value from the
id:
field in the first command. - Click Add secret.
- Click New secret again.
- Name the second secret AZURE_CREDENTIALS and paste the entire contents from the second terminal command you entered.
- Click Add secret
- Back in your pull request, edit the
.github/workflows/deploy-staging.yml
file to use some new actions.
If you'd like to copy the full workflow file, it should look like this:
name: Deploy to staging
on:
pull_request:
types: [labeled]
env:
IMAGE_REGISTRY_URL: ghcr.io
###############################################
### Replace <username> with GitHub username ###
###############################################
DOCKER_IMAGE_NAME: <username>-azure-ttt
AZURE_WEBAPP_NAME: <username>-ttt-app
###############################################
jobs:
build:
if: contains(github.event.pull_request.labels.*.name, 'stage')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
with:
name: webpack artifacts
path: public/
Build-Docker-Image:
runs-on: ubuntu-latest
needs: build
name: Build image and store in GitHub Container Registry
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Download built artifact
uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
- name: Log in to GHCR
uses: docker/login-action@v1.14.1
with:
registry: ${{ env.IMAGE_REGISTRY_URL }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3.7.0
with:
images: ${{env.IMAGE_REGISTRY_URL}}/${{ github.repository }}/${{env.DOCKER_IMAGE_NAME}}
tags: |
type=sha,format=long,prefix=
- name: Build and push Docker image
uses: docker/build-push-action@v2.10.0
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
Deploy-to-Azure:
runs-on: ubuntu-latest
needs: Build-Docker-Image
name: Deploy app container to Azure
steps:
- name: "Login via Azure CLI"
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- uses: azure/docker-login@v1
with:
login-server: ${{env.IMAGE_REGISTRY_URL}}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Deploy web app container
uses: azure/webapps-deploy@v2
with:
app-name: ${{env.AZURE_WEBAPP_NAME}}
images: ${{env.IMAGE_REGISTRY_URL}}/${{ github.repository }}/${{env.DOCKER_IMAGE_NAME}}:${{ github.sha }}
- name: Azure logout
run: |
az logout
- Click Start commit and commit to the
staging-workflow
branch.
Note: Wait about 20 seconds then refresh this page for GitHub Actions to run before continuing to the next step.
GitHub Actions is cloud agnostic, so any cloud will work. We'll show how to deploy to Azure in this course.
What are Azure resources? In Azure, a resource is an entity managed by Azure. We'll use the following Azure resources in this course:
- A web app is how we'll be deploying our application to Azure.
- A resource group is a collection of resources, like web apps and virtual machines (VMs).
- An App Service plan is what runs our web app and manages the billing (our app should run for free).
Through the power of GitHub Actions, we can create, configure, and destroy these resources through our workflow files.
Personal access tokens (PATs) are an alternative to using passwords for authentication to GitHub. We will use a PAT to allow your web app to pull the container image after your workflow pushes a newly built image to the registry.
- Open a new browser tab, and work on the steps in your second tab while you read the instructions in this tab.
- Create a personal access token with the
repo
andread:packages
scopes. For more information, see "Creating a personal access token." - Once you have generated the token we will need to store it in a secret so that it can be used within a workflow. Create a new repository secret named
CR_PAT
and paste the PAT token in as the value. - With this done we can move on to setting up our workflow.
Configuring your Azure environment
To deploy successfully to our Azure environment, we have created a new workflow file spinup-destroy.yml
in the azure-configuration
branch. Review this file in a new browser tab by clicking Pull request and viewing the open pull request.
We will cover the key functionality below and then put the workflow to use by applying a label to the pull request.
This new workflow has two jobs:
- Set up Azure resources will run if the pull request contains a label with the name "spin up environment".
- Destroy Azure resources will run if the pull request contains a label with the name "destroy environment".
In addition to each job, there's a few global environment variables:
AZURE_RESOURCE_GROUP
,AZURE_APP_PLAN
, andAZURE_WEBAPP_NAME
are names for our resource group, app service plan, and web app, respectively, which we'll reference over multiple steps and workflowsAZURE_LOCATION
lets us specify the region for the data centers, where our app will ultimately be deployed.
Setting up Azure resources
The first job sets up the Azure resources as follows:
- Logs into your Azure account with the
azure/login
action. TheAZURE_CREDENTIALS
secret you created earlier is used for authentication. - Creates an Azure resource group by running
az group create
on the Azure CLI, which is pre-installed on the GitHub-hosted runner. - Creates an App Service plan by running
az appservice plan create
on the Azure CLI. - Creates a web app by running
az webapp create
on the Azure CLI. - Configures the newly created web app to use GitHub Packages by using
az webapp config
on the Azure CLI. Azure can be configured to use its own Azure Container Registry, DockerHub, or a custom (private) registry. In this case, we'll configure GitHub Packages as a custom registry.
Destroying Azure resources
The second job destroys Azure resources so that you do not use your free minutes or incur billing. The job works as follows:
- Logs into your Azure account with the
azure/login
action. TheAZURE_CREDENTIALS
secret you created earlier is used for authentication. - Deletes the resource group we created earlier using
az group delete
on the Azure CLI.
- Edit the
spinup-destroy.yml
file in your open pull request and replace any<username>
placeholders with your GitHub username. Commit this change directly to theazure-configuration
branch. - Apply the spin up environment label to your open pull request
- Wait for the GitHub Actions workflow to run and spin up your Azure environment. You can follow along in the Actions tab or in the pull request merge box.
- Once the workflow succeeds, refresh this page for the next step.
Now that the proper configuration and workflow files are present, let's test our actions! In this step, there's a small change to the game. Once you add the appropriate label to your pull request, you should be able to see the deployment!
We have created a new pull request from the staging-test
branch. The only purpose of this pull request is to be able to apply a label and see your application deployed to Azure.
- Ensure that the
GITHUB_TOKEN
for this repository has read and write permissions under Workflow permissions. Learn more. This is required for your workflow to be able to upload your image to the container registry. - Apply the stage label to your open pull request
- Wait for the GitHub Actions workflow to run and deploy the application to your Azure environment. You can follow along in the Actions tab or in the pull request merge box.
The deployment may take a few moments but you've done the right thing. Once the deployment is successful, you'll see green check marks for each run, and you'll see a URL for your deployment.
- Once the workflow has completed, refresh this page for the next step.
We have created a workflow file deploy-prod.yml
in the production-deployment-workflow
branch. Review this file in a new browser tab by clicking Pull request and viewing the open pull request. This new workflow deals specifically with commits to main and handles deployments to prod.
Continuous delivery (CD) is a concept that contains many behaviors and other, more specific concepts. One of those concepts is test in production. That can mean different things to different projects and different companies, and isn't a strict rule that says you are or aren't "doing CD".
In our case, we can match our production environment to be exactly like our staging environment. This minimizes opportunities for surprises once we deploy to production.
- Open a new browser tab, and work on the steps in your second tab while you read the instructions in this tab.
- Open your
deploy-prod.yml
workflow for edit. - Replace any
<username>
placeholders with your GitHub username - Add a
push
trigger - Add branches inside the push block
- Add
- main
inside the branches block
It should look like the file below when you are finished. Note that not much has changed from our staging workflow, except for our trigger, and that we won't be filtering by labels.
name: Production deployment
on:
push:
branches:
- main
env:
IMAGE_REGISTRY_URL: ghcr.io
###############################################
### Replace <username> with GitHub username ###
###############################################
DOCKER_IMAGE_NAME: <username>-azure-ttt
AZURE_WEBAPP_NAME: <username>-ttt-app
###############################################
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
with:
name: webpack artifacts
path: public/
Build-Docker-Image:
runs-on: ubuntu-latest
needs: build
name: Build image and store in GitHub Container Registry
steps:
- name: Checkout
uses: actions/checkout@v1
- name: Download built artifact
uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
- name: Log in to GHCR
uses: docker/login-action@v1.14.1
with:
registry: ${{ env.IMAGE_REGISTRY_URL }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
id: meta
uses: docker/metadata-action@v3.7.0
with:
images: ${{env.IMAGE_REGISTRY_URL}}/${{ github.repository }}/${{env.DOCKER_IMAGE_NAME}}
tags: |
type=sha,format=long,prefix=
- name: Build and push Docker image
uses: docker/build-push-action@v2.10.0
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
Deploy-to-Azure:
runs-on: ubuntu-latest
needs: Build-Docker-Image
name: Deploy app container to Azure
steps:
- name: "Login via Azure CLI"
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- uses: azure/docker-login@v1
with:
login-server: ${{env.IMAGE_REGISTRY_URL}}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Deploy web app container
uses: azure/webapps-deploy@v2
with:
app-name: ${{env.AZURE_WEBAPP_NAME}}
images: ${{env.IMAGE_REGISTRY_URL}}/${{ github.repository }}/${{env.DOCKER_IMAGE_NAME}}:${{github.sha}}
- name: Azure logout
run: |
az logout
- Commit your changes to the
production-deployment-workflow
branch.
Great! The syntax you used tells GitHub Actions to only run that workflow when a commit is made to the main branch. Now we can put this workflow into action to deploy to production!
- You can now merge your pull request!
- Click Merge pull request and leave this tab open as we will be applying a label to the closed pull request in the next step.
- Now we just have to wait for the package to be published to GitHub Container Registry and the deployment to occur. When the workflow is finished running, refresh this page for the next step.
Great work, you've done it! You should be able to see your container image in the Packages section of your account and you can get the deployment URL in the Actions log, just like the staging URL.
Throughout the course you've spun up resources that, if left unattended, could incur billing or consume your free minutes from the cloud provider. Once you have verified your application in production, let's tear down those environments so that you can keep your minutes for more learning!
- Apply the destroy environment label to your merged
production-deployment-workflow
pull request. If you have already closed the tab with your pull request, you can open it again by clicking Pull requests and then clicking the Closed filter to view merged pull requests.
Now that you've applied the proper label, let's wait for the GitHub Actions workflow to complete. When it's finished, you can confirm that your environment has been destroyed by visiting your app's URL, or by logging into the Azure portal to see it is not running.
- Wait about 20 seconds then refresh this page for the next step.
Here's a recap of all the tasks you've accomplished in your repository:
- Trigger a job based on labels
- Set up the Azure environment
- Spin up environment based on labels
- Deploy to a staging environment based on labels
- Deploy to a production environment based on labels
- Destroy environment based on labels
- We'd love to hear what you thought of this course.
- Take another GitHub Skills Course.
- Read the GitHub Getting Started docs.
- To find projects to contribute to, check out GitHub Explore.
Get help: Post in our discussion board • Review the GitHub status page
© 2022 GitHub • Code of Conduct • CC-BY-4.0 License