Deploying with GitHub Actions

Introduction

GitHub 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 "About continuous deployment."

Prerequisites

You should be familiar with the syntax for GitHub Actions. For more information, see "Learn GitHub Actions."

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:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

For more information, see "Events that trigger workflows."

Using environments

Los entornos se usan para describir un destino de implementación general como production, staging o development. Cuando se despliega un flujo de trabajo de GitHub Actions en un ambiente, dicho ambiente se desplegará en la página principal del repositorio. Puedes utilizar ambientes para que requieran la aprobación para que un job proceda, restringir qué ramas pueden activar un flujo de trabajo o limitar el acceso a los secretos. Para obtener más información sobre la creación de entornos, consulte"Uso de entornos para la implementación".

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 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: Deployment

concurrency: production

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - 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: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - 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: Deployment

concurrency: 
  group: production
  cancel-in-progress: true

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

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

Viewing deployment history

When a GitHub 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 "Viewing deployment history."

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, "Using the visualization graph."

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

Tracking deployments through apps

You can also build an app that uses deployment and deployment status webhooks to track deployments. Cuando se ejecuta un trabajo de flujo de trabajo que hace referencia a un entorno, crea un objeto de implementación con la propiedad environment establecida en el nombre del entorno. A medida que avanza el flujo de trabajo, también crea objetos de estado de implementación con la propiedad environment establecida en el nombre del entorno, la propiedad environment_url establecida en la URL del entorno (si se ha especificado en el flujo de trabajo) y la propiedad state establecida en el estado del trabajo. For more information, see "Apps" and "Webhook events and payloads."

Choosing a runner

You can run your deployment workflow on GitHub-hosted runners or on self-hosted runners. Traffic from GitHub-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, GitHub Actions workflows running on GitHub-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 "About self-hosted runners" and "About GitHub-hosted runners."

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. Una insignia de estado muestra si un flujo de trabajo falla o pasa actualmente. Un lugar común para agregar un distintivo de estado es el archivo README.md del repositorio, pero puede agregarlo a la página web que quiera. Predeterminadamente, las insignias muestran el estado de tu rama predeterminada. También puede mostrar el estado de la ejecución de un flujo de trabajo para una rama o evento específicos mediante los parámetros de consulta branch y event en la URL.

For more information, see "Adding a workflow status badge."

Finding deployment examples

This article demonstrated features of GitHub Actions that you can add to your deployment workflows.

GitHub Enterprise Server ofrece flujos de trabajo iniciales para el despliegue para varios servicios populares tales como Azure Web App. Para obtener información sobre cómo empezar a usar un flujo de trabajo de inicio, vea "Uso de flujos de trabajo de inicio" o examine la lista completa de flujos de trabajo de inicio de implementación. También puede consultar flujos de trabajo de implementación específicos en nuestras guías más detalladas, como "Implementación en Azure� App Service".

Muchos proveedores de servicio también ofrecen acciones en GitHub Marketplace para desplegar a su servicio. Para obtener la lista completa, vea GitHub Marketplace.