Continuous Delivery (CD) is the practice of using automation to build, test, configure and deploy from the build environment all the way to the final production environment.
Suppose that your development team is working on the company’s product support website. You’ve already set up continuous integration (CI) by using GitHub Actions and workflows. Now you need to implement CD. Your CI workflow saves a container image. Your CD workflow will deploy this container to your staging and production environments. You’ve talked with IT about how to create and tear down these environments as needed and you’ve all decided to use GitHub Actions and workflows to support infrastructure as code.
In this module, you learn how to use GitHub Actions and workflows to implement a CD solution that deploys a container-based web app to Microsoft Azure Web Apps. You also automate the creation and tear-down of the deployment environments by using a workflow.
Here, we discuss how to use GitHub actions to deploy a container-based web app to Microsoft Azure Web Apps. First, we discuss some options for triggering a workflow. Next, we show you how to work with conditionals in the workflow. Finally, we talk about how to create and delete Azure resources by using GitHub Actions.
Options for triggering a CD workflow
There are several options for starting a CD workflow. Let’s talk about a few of them.
In the previous module on CI with GitHub Actions, you learned how to trigger a workflow from a push to the GitHub repository. However, for CD, you may want to trigger a deployment workflow on some other event.
One option is to trigger the workflow with ChatOps. ChatOps uses chat clients, chatbots and real-time communication tools to execute tasks. For example, you might leave a specific comment in a pull request that can kick off a bot. That bot might comment back with some statistics or run a workflow.
Another option, and the one we use in our example, is to use labels in your pull request. Different labels can start different workflows. For example, add a stage label to begin a deployment workflow to your staging environment, or add a spin up environment label to run the workflow that creates the Microsoft Azure resources you will deploy to best web hosting. To use labels, your workflow will look like this:
on:
pull_request:
types: [labeled]
Control execution with a job conditional
Often, you only want to run a workflow if some condition is true.
GitHub workflows provide the if conditional for this scenario. The conditional uses an expression that will be evaluated at run time. For example, we want to run this workflow if a stage label is added to the pull request.
Store credentials with GitHub Secrets
Of course, you never want to expose sensitive information in the workflow file. GitHub Secrets is a secure place to store sensitive information that your workflow will need. Here’s an example.
In order to deploy to an Azure resource, the GitHub Action must have permission to access the resource. You don’t want to store your Azure credentials in plain sight in the workflow file. Instead, you store your credentials in GitHub Secrets.
To store information in GitHub Secrets, you create a secret on the portal.
Then, you use the name of the secret you created in your workflow wherever you need that information. For example, below we use the Azure credential that was stored in GitHub Secrets in the creds: attribute of an Azure login action. (We talk about that action in the next section.)
Create and delete Azure resources by using GitHub Actions
Because CD is an automated process, you’ve already decided to use infrastructure as code to create and take down the environments you deploy to web hosting . GitHub Actions can automate these tasks on Azure and you can include these actions in your workflow. (Remember that it’s important to tear down resources that you’re no longer using as soon as possible to avoid unnecessary charges.)
One option is to create a new workflow with two jobs, one that spins up resources and one that deletes them. Then, use a conditional to run only the job you want.
Notice that you use GitHub actions to check out the repository and to sign in to Azure. After that, you create the resources you need and deploy the container by using the Azure CLI.
