{"meta":{"title":"Implementación con Acciones de GitHub","intro":"GitHub Actions proporciona un control detallado sobre las implementaciones con entornos, grupos de concurrencia y reglas de protección.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/how-tos","title":"Procedimientos"},{"href":"/es/actions/how-tos/deploy","title":"Desplegar"},{"href":"/es/actions/how-tos/deploy/configure-and-manage-deployments","title":"Configura y administra implementaciones"},{"href":"/es/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"Control de implementaciones"}],"documentType":"article"},"body":"# Implementación con Acciones de GitHub\n\nGitHub Actions proporciona un control detallado sobre las implementaciones con entornos, grupos de concurrencia y reglas de protección.\n\n## Requisitos previos\n\nDebe estar familiarizado con la sintaxis de GitHub Actions. Para más información, consulta [Escritura de flujos de trabajo](/es/actions/how-tos/write-workflows).\n\n## Activar tu despliegue\n\nPuedes utilizar varios eventos para activar tu flujo de trabajo de despliegue. Algunos de los más comunes son: `pull_request`, `push` y `workflow_dispatch`.\n\nPor ejemplo, un flujo de trabajo con los siguientes activadores se ejecuta en cualquier momento:\n\n* Hay una inserción en la rama `main`.\n* Una solicitud de incorporación de cambios dirigida a la rama `main` se ha abierto, sincronizado o vuelto a abrir.\n* Alguien lo activó manualmente.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\nPara más información, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Usar entornos\n\nLos entornos se usan para describir un destino de implementación general como `production`, `staging` o `development`. Cuando un GitHub Actions flujo de trabajo se implementa en un entorno, el entorno se muestra en la página principal del repositorio. Puedes usar entornos para requerir aprobación para que un trabajo continúe, restringir qué ramas pueden desencadenar un flujo de trabajo, controlar las implementaciones con reglas de protección de implementación personalizadas o limitar el acceso a los secretos. Para más información sobre la creación de entornos, consulta [Administrar entornos para la implementación](/es/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\nPuedes configurar ambientes con reglas de protección y secretos. Cuando una tarea de un flujo de trabajo hace referencia a un entorno, la tarea no comenzará hasta que todas las reglas de protección del entorno se cumplan. Un trabajo tampoco puede acceder a los secretos que se definen en un ambiente hasta que se superen todas las reglas de protección de implementación. Para obtener más información, consulta [Uso de reglas de protección de implementación](#using-custom-deployment-protection-rules) personalizadas en este artículo.\n\n## Utilizar la concurrencia\n\nLa concurrencia garantiza que solo una tarea o flujo de trabajo que utilice el mismo grupo de concurrencia se ejecute a la vez. Puede usar la simultaneidad para que un entorno tenga un máximo de una implementación en curso a la vez. Para obtener más información sobre simultaneidad, consulta [Control de la simultaneidad de flujos de trabajo y tareas](/es/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency).\n\n## Uso de entornos sin implementaciones\n\nDe forma predeterminada, cuando un trabajo de flujo de trabajo hace referencia a un entorno, GitHub crea un objeto de implementación para realizar un seguimiento de la implementación. Puede optar por no participar en la creación de la implementación estableciendo `deployment` a `false` en la configuración del entorno. Los valores válidos son `true` (valor predeterminado) y `false`. También puede usar una expresión, por ejemplo `deployment: ${{ github.ref_name == 'main' }}`.\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\nCuando `deployment` se establece en `false`:\n\n* El trabajo tiene acceso total a los secretos y las variables del entorno.\n* No se crea ningún GitHub objeto de implementación: el historial de implementación del entorno no se actualiza.\n* Las reglas de protección del temporizador de espera siguen siendo aplicables: el trabajo espera el tiempo configurado.\n* Los revisores necesarios siguen siendo aplicables: los revisores deben aprobar antes de que se ejecute el trabajo.\n\nEsto resulta útil cuando desea usar entornos para:\n\n* **Organización de secretos**: agrupa los secretos relacionados con un nombre de entorno sin crear registros de implementación.\n* **Control de acceso**: restrinja qué ramas pueden usar determinados secretos a través de directivas de rama de entorno, sin seguimiento de implementación.\n* **Trabajos de CI y pruebas**: haga referencia a un entorno para su configuración sin agregar ruido al historial de implementación.\n\n### Interacción con reglas de protección\n\nLa `deployment` propiedad controla qué reglas de protección se aplican:\n\n\\| Regla de protección |\n`deployment: true` (valor predeterminado) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **Ninguno** | Implementación creada, el trabajo se ejecuta | Sin implementación, el trabajo se ejecuta |\n\\| **Temporizador de espera** | Temporizador de espera aplicado | El temporizador de espera sigue siendo aplicado |\n\\| **Revisores necesarios** | Los revisores deben aprobar | Los revisores deben aprobar |\n\\| **Aplicación de reglas personalizadas de protección de implementación** | Webhook de la aplicación enviado, se debe aprobar |\n**El trabajo falla con error** |\n\nLas reglas de protección de implementación personalizadas (GitHub Apps) requieren un objeto de implementación para funcionar. Si establece `deployment: false` en un entorno que tiene reglas de protección de implementación customizadas, el trabajo fallará inmediatamente con un mensaje de error o anotación que explica que las reglas de protección del entorno no son compatibles con `deployment: false`. Quite `deployment: false` de su flujo de trabajo, o quite las reglas personalizadas de protección de implementación de su entorno.\n\nTenga en cuenta que `concurrency` y `environment` no están conectados. El valor de concurrencia puede ser cualquier secuencia; no necesita ser un nombre de ambiente. Adicionalmente, si otro flujo de trabajo utiliza el mismo ambiente pero no especifica una concurrencia, este no estará sujeto a ninguna regla de concurrencia.\n\nPor ejemplo, cuando se ejecuta el siguiente flujo de trabajo, se pausará con el estado `pending` si cualquier trabajo o flujo de trabajo que utiliza el grupo de simultaneidad `production` está en curso. También cancelará cualquier trabajo o flujo de trabajo que use el grupo de simultaneidad `production` y tenga el estado `pending`. Esto significa que habrá un máximo de un trabajo o flujo de trabajo en ejecución, y un trabajo o flujo de trabajo pendiente que utilice el grupo de simultaneidad `production`.\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nTambién puedes especificar la concurrencia a nivel del job. Esto permitirá que los demás trabajos del flujo de trabajo continúen aunque el trabajo simultáneo sea `pending`.\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nTambién puede usar `cancel-in-progress` para cancelar cualquier trabajo o flujo de trabajo actualmente en ejecución en el mismo grupo de simultaneidad.\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nPara obtener instrucciones sobre cómo escribir pasos específicos de la implementación, consulta [Búsqueda de ejemplos de implementación](#finding-deployment-examples).\n\n## Visualización del historial de implementación\n\nCuando un GitHub Actions flujo de trabajo se implementa en un entorno, el entorno se muestra en la página principal del repositorio. Para obtener más información sobre cómo ver las implementaciones en los entornos, consulta [Visualización del historial de implementación](/es/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history).\n\nSu organización puede recopilar registros de implementación para todas las compilaciones en un solo lugar mediante la carga de datos en el linked artifacts page. Consulta [Acerca de los artefactos vinculados](/es/code-security/concepts/supply-chain-security/linked-artifacts).\n\n## Monitorear las ejecuciones de flujo de trabajo\n\nCada ejecución de flujo de trabajo genera una gráfica en tiempo real que ilustra el progreso de la misma. Puedes utilizar esta gráfica para monitorear y depurar los despliegues. Para obtener más información, consulta [Utilizar la gráfica de visualización](/es/actions/how-tos/monitor-workflows/use-the-visualization-graph).\n\nTambién puedes ver las bitácoras de cada ejecución de flujo de trabajo y el historial de estos. Para más información, consulta [Visualizar el historial de ejecución del flujo de trabajo](/es/actions/how-tos/monitor-workflows/view-workflow-run-history).\n\n## Uso de las revisiones obligatorias en flujos de trabajo\n\nLas tareas que se refieren a un entorno configurado con los revisores necesarios esperarán una aprobación antes de comenzar. Mientras un trabajo espera su aprobación, tendrá un estado de \"En espera\". Si un trabajo no se aprueba en un plazo de 30 días, fallará automáticamente.\n\nPara más información sobre los entornos y las aprobaciones necesarias, consulta [Administrar entornos para la implementación](/es/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Para información sobre cómo revisar las implementaciones con la API de REST, consulta [Puntos de conexión de API de REST para ejecuciones de flujo de trabajo](/es/rest/actions/workflow-runs).\n\n## Uso de reglas de protección de implementación personalizadas\n\n> \\[!NOTE]\n> Las reglas de protección de implementación personalizadas se encuentran actualmente en versión preliminar pública y están sujetas a cambios.\n\nPuede habilitar sus propias reglas de protección personalizadas para controlar las implementaciones con servicios de terceros. Por ejemplo, puede usar servicios como Datadog, Honeycomb y ServiceNow para proporcionar aprobaciones automatizadas para implementaciones en GitHub.\n\nLas reglas de protección de implementación personalizadas funcionan GitHub Apps y se ejecutan en función de webhooks y devoluciones de llamada. La aprobación o el rechazo de un trabajo de flujo de trabajo se basa en el consumo del webhook `deployment_protection_rule`. Para obtener más información, consulta [Eventos y cargas de webhook](/es/webhooks/webhook-events-and-payloads#deployment_protection_rule) y [Aprobación o rechazo de implementaciones](/es/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules#approving-or-rejecting-deployments).\n\nCuando hayas creado una regla de protección de implementación personalizada y la hayas instalado en el repositorio, la regla de protección de implementación personalizada estará disponible automáticamente para todos los entornos del repositorio.\n\nLas implementaciones en un entorno se pueden aprobar o rechazar en función de las condiciones definidas en cualquier servicio externo, como una incidencia aprobada en un sistema de gestión de servicios de TI (ITSM), el resultado del análisis de vulnerabilidad en las dependencias o las métricas de salud estables de un recurso en la nube. La decisión de aprobar o rechazar implementaciones es a discreción de la integración de la aplicación de terceros y las condiciones de acceso que defina en ellas. A continuación se muestran algunos casos de uso para los que puedes crear una regla de protección de implementación.\n\n* ITSM & Operaciones de seguridad: puedes comprobar la preparación del servicio validando los procesos de calidad, seguridad y cumplimiento que comprueban la preparación de la implementación.\n* Sistemas de observabilidad: puedes consultar sistemas de supervisión o observabilidad (sistemas de administración de rendimiento de recursos y agregadores de registro, sistemas de verificación de estado de recursos en la nube, etc.) para comprobar la seguridad y la preparación de la implementación.\n* Herramientas de prueba y de calidad del código: puedes comprobar si hay pruebas automatizadas en compilaciones de CI que deben implementarse en un entorno.\n\nComo alternativa, puedes escribir tus propias reglas de protección para cualquiera de los casos de uso anteriores o puedes definir cualquier lógica personalizada para aprobar o rechazar de forma segura las implementaciones de preproducción a entornos de producción.\n\n## Rastrear los despliegues a través de las apps\n\nSi su cuenta personal o su organización en GitHub están integradas con Microsoft Teams o Slack, puede realizar un seguimiento de las implementaciones que utilizan entornos mediante Microsoft Teams o Slack. Por ejemplo, puedes recibir notificaciones a través de la app cuando la aprobación de un despliegue está pendiente, cuando está aprobado o cuando cambia su estado. Para obtener más información sobre la integración de Microsoft Teams o Slack, consulte [Integraciones de GitHub destacadas](/es/integrations/concepts/featured-github-integrations#team-communication-tools).\n\nTambién puedes crear una app que utilice webhooks para el rastreo de las implementaciones y de su estado.\nCuando 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. Para obtener más información, consulte [Documentación de GitHub Apps](/es/apps) y [Eventos y cargas de webhook](/es/webhooks/webhook-events-and-payloads#deployment).\n\n## Elegir un ejecutor\n\nPuede ejecutar el flujo de trabajo de implementación en ejecutores hospedados en GitHub o en ejecutores autohospedados. El tráfico desde ejecutores hospedados en GitHub puede provenir de una [amplia gama de direcciones de red](/es/rest/meta/meta#get-github-meta-information). Si va a implementar en un entorno interno y su empresa restringe el tráfico externo a redes privadas, es posible que los flujos de trabajo GitHub Actions que se ejecutan en ejecutores hospedados en GitHub no puedan comunicarse con los servicios o recursos internos. Para superar esto, puedes hospedar tus propios ejecutores. Para más información, consulta [Ejecutores autohospedados](/es/actions/concepts/runners/self-hosted-runners) y [Ejecutores hospedados en GitHub](/es/actions/concepts/runners/github-hosted-runners).\n\n## Mostrar una insignia de estado\n\nPuedes utilizar una insignia de estado para mostrar el estado de tu flujo de trabajo de despliegue. 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. Si no hay ninguna ejecución de flujo de trabajo en la rama predeterminada, se mostrará el estado de la ejecución más reciente en todas las ramas. 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.\n\n![Captura de pantalla de una notificación de estado de flujo de trabajo. De derecha a izquierda, se muestra: el logotipo de GitHub, el nombre del flujo de trabajo (\"Demostración de Acciones de GitHub\") y el estado (\"paso\").](/assets/images/help/repository/actions-workflow-status-badge.png)\n\nPara más información, consulta [Adición de un distintivo de estado de flujo de trabajo](/es/actions/how-tos/monitor-workflows/add-a-status-badge).\n\n## Encontrar ejemplos de despliegues\n\nEn este artículo se demuestran las características de GitHub Actions que puede agregar a los flujos de trabajo de implementación.\n\nGitHubofrece plantillas de flujo de trabajo de implementación para varios servicios populares, como Azure Aplicación web. Para obtener información sobre cómo empezar a usar una plantilla de flujo de trabajo, consulta [Uso de plantillas de flujo de trabajo](/es/actions/how-tos/write-workflows/use-workflow-templates), o bien [examina la lista completa de plantillas de flujo de trabajo de implementación](https://github.com/actions/starter-workflows/tree/main/deployments). También puedes consultar flujos de trabajo de implementación específicos en nuestras guías más detalladas, como [Implementación de Node.js en Azure App Service](/es/actions/how-tos/deploy/deploy-to-third-party-platforms/nodejs-to-azure-app-service).\n\nMuchos proveedores de servicios también ofrecen acciones en GitHub Marketplace para implementar en su servicio. Para obtener la lista completa, vea [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)."}