deploying-with-github-actions.md

title	intro	versions	type	redirect_from	topics	shortTitle
Deploying with GitHub Actions	Learn how to control deployments with features like environments and concurrency.	fpt ghes ghec * * *	overview	/actions/deployment/deploying-with-github-actions /actions/deployment/about-deployments/deploying-with-github-actions	CD Deployment	Deploy with GitHub Actions

{% data reusables.actions.enterprise-github-hosted-runners %}

Introduction

{% data variables.product.prodname_actions %} offers features that let you control deployments. You can:

• Trigger workflows with a variety of events.
• Configure environments to set rules before a job can proceed and to limit access to secrets.
• Use concurrency to control the number of deployments running at a time.

For more information about continuous deployment, see AUTOTITLE.

Prerequisites

You should be familiar with the syntax for {% data variables.product.prodname_actions %}. For more information, see AUTOTITLE.

Triggering your deployment

You can use a variety of events to trigger your deployment workflow. Some of the most common are: pull_request, push, and workflow_dispatch.

For example, a workflow with the following triggers runs whenever:

• There is a push to the main branch.
• A pull request targeting the main branch is opened, synchronized, or reopened.
• Someone manually triggers it.

on: push: branches: - mainpull_request: branches: - mainworkflow_dispatch:

For more information, see AUTOTITLE.

Using environments

{% data reusables.actions.about-environments %}

Using concurrency

Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see AUTOTITLE.

Note

concurrency and environment are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.

For example, when the following workflow runs, it will be paused with the status pending if any job or workflow that uses the production concurrency group is in progress. It will also cancel any job or workflow that uses the production concurrency group and has the status pending. This means that there will be a maximum of one running and one pending job or workflow in that uses the production concurrency group.

name: Deploymentconcurrency: productionon: push: branches: - mainjobs: deployment: runs-on: ubuntu-latestenvironment: productionsteps: - name: deploy# ...deployment-specific steps

You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is pending.

name: Deploymenton: push: branches: - mainjobs: deployment: runs-on: ubuntu-latestenvironment: productionconcurrency: productionsteps: - name: deploy# ...deployment-specific steps

You can also use cancel-in-progress to cancel any currently running job or workflow in the same concurrency group.

name: Deploymentconcurrency: group: productioncancel-in-progress: trueon: push: branches: - mainjobs: deployment: runs-on: ubuntu-latestenvironment: productionsteps: - name: deploy# ...deployment-specific steps

For guidance on writing deployment-specific steps, see Finding deployment examples.

Viewing deployment history

When a {% data variables.product.prodname_actions %} workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see AUTOTITLE.

Monitoring workflow runs

Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, AUTOTITLE.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see AUTOTITLE.

Tracking deployments through apps

{% ifversion fpt or ghec %} If your personal account or organization on {% data variables.product.github %} is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating Microsoft Teams or Slack, see AUTOTITLE. {% endif %}

You can also build an app that uses deployment and deployment status webhooks to track deployments. {% data reusables.actions.environment-deployment-event %} For more information, see AUTOTITLE and AUTOTITLE.

Choosing a runner

You can run your deployment workflow on {% data variables.product.company_short %}-hosted runners or on self-hosted runners. Traffic from {% data variables.product.company_short %}-hosted runners can come from a wide range of network addresses. If you are deploying to an internal environment and your company restricts external traffic into private networks, {% data variables.product.prodname_actions %} workflows running on {% data variables.product.company_short %}-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see AUTOTITLE and AUTOTITLE.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. {% data reusables.repositories.actions-workflow-status-badge-intro %}

For more information, see AUTOTITLE.

Finding deployment examples

This article demonstrated features of {% data variables.product.prodname_actions %} that you can add to your deployment workflows.

{% data reusables.actions.cd-templates-actions %}