Crear y dirigir un entorno

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Un entorno es una colección de recursos a los que puede dirigirse con implementaciones de una canalización. Algunos ejemplos comunes de los nombres de entorno son Dev, Test, QA, Staging y Production. Un entorno de Azure DevOps representa un destino lógico donde la canalización implementa software.

Los entornos de Azure DevOps no están disponibles en canalizaciones clásicas. En el caso de las canalizaciones clásicas, los grupos de implementación ofrecen una funcionalidad similar.

Los entornos proporcionan las ventajas siguientes.

Prestación	Descripción
Historial de implementación	El nombre de la canalización y los detalles de ejecución se registran para las implementaciones en un entorno y sus recursos. En el contexto de varias canalizaciones destinadas al mismo entorno o recurso, el historial de implementación de un entorno es útil para identificar el origen de los cambios.
Rastreabilidad de confirmaciones y elementos de trabajo	Vea los trabajos dentro de la ejecución de canalización que tienen como destino un entorno. También puede ver las confirmaciones y los elementos de trabajo que han sido recién implementados en el entorno. La rastreabilidad también permite realizar un seguimiento si un cambio de código (confirmación) o una característica o corrección de errores (elementos de trabajo) alcanza un entorno.
Estado de los recursos de diagnóstico	Validar si la aplicación funciona en su estado deseado.
Seguridad	Entornos seguros que especifican qué usuarios y canalizaciones pueden tener como destino un entorno.

Aunque un entorno es una agrupación de recursos, los recursos en sí representan destinos de implementación reales. Actualmente se admiten el recurso Kubernetes y los tipos de recursos de máquina virtual.

Al crear una canalización YAML y hacer referencia a un entorno que no existe, Azure Pipelines crea automáticamente el entorno cuando se sabe quién es el usuario que realiza la operación y asigna permisos. Cuando Azure Pipelines no tiene información sobre el usuario que crea el entorno (ejemplo: una actualización de YAML desde un editor de código externo), se produce un error en la canalización si el entorno aún no existe.

Requisitos previos

• Debe tener elrol Creador para entornos para agregar un entorno.

Creación de un entorno

1. Inicie sesión en la organización: https://dev.azure.com/{yourorganization} y vaya a su proyecto.

2. Seleccione Entornos> de canalizaciones>Crear entorno.

   

3. Escriba la información del entorno y, a continuación, seleccione Crear. Los recursos se pueden agregar a un entorno existente más adelante.

   

Use también una canalización para crear e implementar en entornos. Para obtener más información, consulte la guía paso a paso.

Sugerencia

Puede crear un entorno vacío y hacer referencia a él desde los trabajos de implementación. Esta posibilidad le permite registrar el historial de implementación con respecto al entorno.

Establecer como destino un entorno desde un trabajo de implementación

Un trabajo de implementación es una colección de pasos que se ejecutarán secuencialmente. Un trabajo de implementación se puede usar para tener como destino un entorno completo (grupo de recursos), como se muestra en el siguiente fragmento de código YAML. La canalización se ejecutará en la máquina myVM como especifica el nombre del recurso.

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

Establecer como destino un recurso específico dentro de un entorno desde el trabajo de implementación

Puede definir el ámbito del destino de la implementación en un recurso determinado dentro del entorno. A continuación, puede registrar el historial de implementación en un recurso específico dentro del entorno. Los pasos del trabajo de implementación heredan automáticamente los detalles de conexión de servicio del recurso de destino del trabajo de implementación.

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

Detalles de la ejecución del entorno

Todos los entornos que se destinan a los trabajos de implementación de una ejecución específica de una canalización se pueden encontrar en la pestaña Entornos de los detalles de la ejecución de la canalización.

Si usa un clúster privado de AKS, la pestaña Entornos no está disponible.

Aprobaciones

Controle manualmente cuándo se debe ejecutar una fase mediante comprobaciones de aprobación. Use comprobaciones de aprobación para controlar las implementaciones en entornos de producción. Las comprobaciones están disponibles para el propietario del recurso para controlar cuándo una fase de una canalización consume un recurso. Como propietario de un recurso, como un entorno, puede definir aprobaciones y comprobaciones que deben cumplirse antes de que se inicie una fase que consuma ese recurso.

Se admiten comprobaciones manuales de aprobación en entornos. Para obtener más información, consulte Aprobaciones.

Los roles de creador, administrador y usuario pueden administrar aprobaciones y comprobaciones. El rol Lector no puede administrar aprobaciones y comprobaciones.

Historial de implementación

La vista del historial de implementación en entornos proporciona las siguientes ventajas.

• Vea los trabajos de todas las canalizaciones destinadas a un entorno específico. Por ejemplo, ambos microservicios, cada uno con su propia canalización, se implementan en el mismo entorno. La lista del historial de implementación ayuda a identificar todas las canalizaciones que afectan a este entorno y también ayuda a visualizar la secuencia de implementaciones por cada canalización.

  

• Explore en profundidad los detalles del trabajo para ver la lista de confirmaciones y elementos de trabajo que se implementaron en el entorno. La lista de confirmaciones y elementos de trabajo son los nuevos elementos entre implementaciones. La primera lista incluye todas las confirmaciones, pero las siguientes solo incluirán cambios. Si varias confirmaciones están vinculadas a la misma solicitud de incorporación de cambios, verá varios resultados en los elementos de trabajo y pestañas de cambios.

  

• Si varios elementos de trabajo están vinculados a la misma solicitud de incorporación de cambios, verá varios resultados en la pestaña de elementos de trabajo.

  

Seguridad

Permisos de usuario

Controle quién puede crear, ver, usar y administrar los entornos con permisos de usuario. Hay cuatro roles: Creator (ámbito: todos los entornos), Lector, Usuario y Administrador. En el panel Permisos de usuario del entorno específico, puede establecer los permisos que se heredan y puede invalidar los roles de cada entorno.

1. Vaya al Entorno específico que desea autorizar.
2. Seleccione >Seguridad para ver la configuración.
3. Seleccione Permisos de usuario>+ Añadir>usuario o grupo y, a continuación, seleccione un rol adecuado.

Role	Descripción
Creador	Rol global, disponible en la opción de seguridad del centro de entornos. Los miembros con este rol pueden crear el entorno en el proyecto. Los colaboradores se agregan como miembros de forma predeterminada. Es necesario para desencadenar una canalización YAML cuando el entorno aún no existe.
Lector	Los miembros con este rol pueden ver el elemento.
User	Los miembros con este rol pueden usar el entorno al crear o editar canalizaciones YAML.
Administrador	Los miembros de este rol pueden administrar permisos, crear, administrar, ver y usar entornos. Para un entorno concreto, su creador se añade como Administrador de forma predeterminada. Los administradores también puede abrir el acceso a un entorno a todas las canalizaciones.

Permisos de canalización

Use permisos de canalización para autorizar las canalizaciones seleccionadas, o todas, para la implementarlas al entorno.

• Para quitar Abrir acceso en el entorno o recurso, seleccione Restringir permiso en Permisos de canalización.
• Para permitir que canalizaciones específicas se implementen en un entorno o en un recurso específico, seleccione + y elija las que sean en la lista de canalizaciones.

Pasos siguientes

Definición de aprobaciones y comprobaciones

Preguntas más frecuentes

P: ¿Por qué me sale un mensaje de error cuando intento crear un entorno?

R: Si ve el mensaje "Acceso denegado: {User} necesita crear permisos para realizar la acción", compruebe los permisos de nivel de organización. Vaya a Configuración de la organización>Usuarios y compruebe si tiene el rol de parte interesada. El rol de parte interesada no puede crear entornos. Cambie el nivel de acceso y compruebe si puede crear entornos. Para obtener más información, consulte Preguntas más frecuentes sobre la administración de usuarios y permisos.

P: ¿Por qué me sale el error "Trabajo XXXX: No se ha podido encontrar el entorno XXXX. El entorno no existe o no se ha autorizado su uso"?

R: Estas son algunas de las posibles razones del error:

• Cuando crea una canalización YAML y hace referencia a un entorno que no existe en el archivo YAML, Azure Pipelines crea automáticamente el entorno en algunos casos:

  • Utilizas el asistente de creación de canalizaciones YAML en la experiencia web de Azure Pipelines y haces referencia a un entorno que aún no se ha creado.
  • Actualizas el archivo YAML con el editor web de Azure Pipelines y guardas la canalización después de agregar una referencia a un entorno que no existe.

• En los siguientes flujos, Azure Pipelines no tiene información sobre el usuario que crea el entorno: usted actualiza el archivo YAML con otro editor de código externo, agrega una referencia a un entorno que no existe y luego hace que una canalización de integración continua o manual se active. En este caso, Azure Pipelines no conoce al usuario. Anteriormente, se ha controlado este caso agregando todos los colaboradores del proyecto al rol de administrador del entorno. Cualquier miembro del proyecto podría cambiar estos permisos e impedir que otros usuarios accedan al entorno.

• Puede usar variables para crear el entorno o usar templateContext para pasar propiedades a plantillas. Los parámetros en tiempo de ejecución no funcionarán al crear el entorno porque se expanden en el tiempo de ejecución.

• Un usuario con el nivel de acceso de las partes interesadas no puede crear el entorno, ya que las partes interesadas no tienen acceso al repositorio.

Artículos relacionados

• Definición de variables
• Definir recursos en YAML