Compartir a través de

Grupos de DevOps administrados para Azure DevOps (versión preliminar)

Nos complace anunciar la versión preliminar de Managed DevOps Pools, diseñada para ayudar a los equipos de desarrollo e ingeniería de plataforma a configurar y administrar rápidamente grupos de DevOps personalizados.

Además, hemos mejorado las API de estimación de uso de medidores para GitHub Advanced Security, lo que proporciona nuevas funcionalidades que le ayudan a identificar a los usuarios.

Consulte las notas de publicación para más detalles.

Seguridad avanzada de GitHub para Azure DevOps

Azure Pipelines (Canales de Azure)

Seguridad avanzada de GitHub para Azure DevOps

La API de uso de medidores de Advanced Security ahora devuelve identidades de usuario

Para ayudarle a identificar a los usuarios de Advanced Security, las API de estimación de uso de medidores ahora devuelven la identidad de Azure DevOps de cada usuario, incluido su nombre para mostrar, CUID, identificador de correo electrónico e descriptor de identidad. Esta característica está disponible en los niveles de organización, proyecto y repositorio. Para usar este nuevo punto de conexión, la sintaxis es similar a la de los puntos de conexión existentes de la API de uso de medidores, agregando /details al punto de conexión.

  • En el nivel de organización: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • En el nivel de proyecto: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • En el nivel de repositorio: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

Examen de código de GitHub Advanced Security para proyectos de C# y Java sin compilaciones

El análisis de código con CodeQL implica la ejecución de consultas en bases de datos que representan el código del repositorio para un solo idioma. En el caso de lenguajes compilados como C/C++, C#, Go, Java y Swift, esto normalmente requiere compilar el código primero.

Sin embargo, CodeQL, el motor de análisis estático detrás de Seguridad avanzada de GitHub para Azure DevOps, ahora puede examinar proyectos de C# y Java sin necesidad de una compilación. Cuando el modo de compilación se establece en "none", la base de datos CodeQL se genera directamente desde el código base, pasando el paso de compilación.

Para todos los lenguajes compilados, el modo de compilación predeterminado es "manual". Sin embargo, para C# y Java, puede cambiar el modo de compilación a "none".

Puede configurar el modo de compilación durante la configuración advancedSecurity-Codeql-Init@1. Para obtener instrucciones detalladas sobre cómo configurar el examen de código en GitHub Advanced Security con Azure DevOps, consulte Configuración del examen de código.

Consideración:

  • Si se selecciona "none" y un lenguaje distinto de los lenguajes compatibles C# o Java compatibles, es posible que la tarea de canalización no funcione según lo previsto.

  • El modo de compilación "none" funciona actualmente junto con otros lenguajes interpretados (por ejemplo, JavaScript, Python, Ruby).

  • Ejemplo válido: C# y JavaScript con el modo de compilación establecido en "none". (JavaScript en un lenguaje interpretado)

  • Ejemplo no válido: C#, JavaScript y Swift con el modo de compilación establecido en "none" (Swift no se admite en el modo de compilación "none").

Captura de pantalla de AdvancedSecurity-Codeql.

Azure Pipelines (Canales de Azure)

Grupos de DevOps administrados (versión preliminar)

Los equipos de ingeniería se destacan cuando pueden centrarse en escribir código para desarrollar aplicaciones y servicios para sus usuarios. Sin embargo, en la práctica, una cantidad considerable de tiempo suele dedicarse a administrar otras tareas, como el mantenimiento de la infraestructura de DevOps.

Nos complace anunciar la versión preliminar pública de grupos de DevOps administrados (MDP), una nueva característica de Azure DevOps diseñada para ayudar a los equipos de desarrollo e ingeniería de plataforma a implementar grupos de DevOps personalizados adaptados a sus necesidades únicas. MDP combina la flexibilidad de los agentes de conjunto de escalado con la facilidad de mantenimiento asociado a los agentes hospedados por Microsoft, lo que permite a los equipos establecer coherencia y procedimientos recomendados al optimizar el rendimiento, la seguridad, el cumplimiento y la rentabilidad.

Entre las principales ventajas de los grupos de DevOps administrados se incluyen:

  • Hospedado en su nombre: Microsoft hospeda y administra MDP, con las máquinas virtuales que potencian los agentes creados y mantenidos dentro de las suscripciones de Azure propiedad de Microsoft.
  • Tiempo invertido en administración: MDP reduce significativamente el tiempo dedicado a administrar agentes, especialmente aquellos basados en la infraestructura local o en sistemas mantenidos manualmente.
  • Grupos específicos: Debido a la facilidad con la que se pueden crear nuevos grupos, las organizaciones pueden crear fácilmente varios grupos específicos del equipo o específicos de la carga de trabajo.
  • Facturación de DevOps: MDP ayuda a optimizar la factura de DevOps de un equipo a través de muchas características. Facilita a los equipos encontrar un equilibrio óptimo entre el QoS/rendimiento y el costo de un conjunto de recursos.
  • Escalable: MDP escala hasta miles de agentes en un único grupo.

Teams puede crear grupos con imágenes de inicio rápido que contengan el mismo software presente en agentes hospedados de Microsoft o con imágenes que el equipo ha creado con requisitos previos que son únicos para su escenario.

Para más información sobre los grupos de DevOps administrados, lea nuestra entrada de blog o su documentación.

Las tareas de Azure Pipelines usan node 20

La mayoría de las tareas de canalización usan Node como ejecutor. La tarea de las canalizaciones de Azure que usa NodeJS como ejecutor ahora utiliza NodeJS 20. Los autores de extensiones de tareas deben actualizar sus tareas para usar Node 20. Para obtener instrucciones sobre cómo actualizar, consulte ¿Cómo puedo actualizar mi tarea personalizada al nodo más reciente?.

Creación del permiso de canalización de compilación

Para aumentar la seguridad de la canalización, vamos a introducir un nuevo permiso, Create build pipeline, en el nivel de canalizaciones.

Captura de pantalla del permiso de creación de tubería de compilación.

Anteriormente, se requería el Edit build pipeline permiso para crear o editar una canalización. Esto representaba un riesgo de seguridad, ya que permitía a todos los usuarios con la capacidad de crear canalizaciones también editar las canalizaciones que no habían creado. Impedir que esto consuma mucho tiempo.

Para mejorar la experiencia de canalización sin poner en peligro la seguridad, todos los usuarios y grupos con el Edit build pipeline permiso ahora también recibirán el Create build pipeline permiso.

Cuando se crea una canalización, a su creador se le concede el Edit build pipeline permiso.

Para mejorar la seguridad de la canalización, puede optar por quitar el Edit build pipeline permiso de los grupos de usuarios, como colaboradores y lectores. Esto garantiza que, de forma predeterminada, solo el creador de la canalización puede editarlo.

Nota:

El permiso Editar canalización de compilación no impide que otros usuarios editen la canalización YAML; solo protege las propiedades de la canalización de ser editadas.

En el caso de los nuevos proyectos, los usuarios y grupos con permiso de Edit build pipeline también dispondrán de permiso de Create build pipeline. Esto está sujeto a cambios en el futuro.

Comprobación de bloqueo exclusiva en el nivel de fase

Algunos casos de uso requieren una canalización para acceder a un recurso específico solo una vez en un momento dado. Para apoyar este caso, tenemos la comprobación de bloqueo exclusivo.

Se produce una situación similar cuando solo una ejecución del pipeline debe acceder a una etapa en cualquier momento dado. Por ejemplo, si tiene una fase que se implementa en un grupo de recursos de Azure, puede impedir que varias ejecuciones de canalización actualicen simultáneamente el mismo grupo de recursos. Actualmente, lograr esto requiere el uso de un recurso proxy, como un entorno, y colocar la verificación de bloqueo exclusivo en ese entorno. Este enfoque puede llevar mucho tiempo, agregar complejidad y aumentar los esfuerzos de mantenimiento.

En este sprint, presentamos compatibilidad para especificar el bloqueo exclusivo en el nivel de etapa. Si tiene una etapa con un identificador y especifica su propiedad lockBehavior, se crea automáticamente un bloqueo para esa etapa. El sequential comportamiento sigue siendo coherente tanto para los bloqueos a nivel de recurso como para los bloqueos de fase. Sin embargo, el runLatest comportamiento difiere, ya que solo cancela las compilaciones runLatest de la misma rama y no para todas las ramas de la canalización.

Información de plantilla en ejecuciones de canalización

Hemos actualizado la API REST de "Pipelines Runs - Get" con información sobre las plantillas extendidas e incluidas en las ejecuciones de canalización.

Por ejemplo, considere que tiene el siguiente código de canalización de YAML:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

La nueva API REST tiene las siguientes propiedades nuevas:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Fases de canalización YAML desencadenadas manualmente

Con frecuencia se reciben solicitudes sobre las fases de canalización YAML desencadenadas manualmente. Esto resulta útil cuando desea una canalización unificada, pero no siempre quiere que se ejecute hasta la finalización.

Por ejemplo, la canalización puede incluir fases para compilar, probar, implementar en un entorno de ensayo e implementar en producción. Es posible que quiera que todas las fases se ejecuten automáticamente, excepto la implementación en producción, que prefiere desencadenar manualmente cuando esté lista.

Con este sprint, se agrega compatibilidad con las fases de canalización YAML desencadenadas manualmente. Para usar esta función, debe agregar la propiedad trigger: manual a una etapa.

Tenga en cuenta el siguiente ejemplo de canalización de YAML:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Al ejecutar este pipeline, la experiencia es la siguiente:

Captura de pantalla de las fases de canalización YAML desencadenadas manualmente.

Las fases desencadenadas manualmente no tienen dependencias y se pueden ejecutar en cualquier momento. La ejecución de la canalización se completa cuando solo quedan por ejecutarse las fases desencadenadas manualmente.

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Ir a Azure DevOps

Cómo proporcionar comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú ayuda para notificar un problema o proporcionar una sugerencia.

Hacer una sugerencia

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias

Silviu Andrica

  • Last updated on