Compartir a través de

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

  • Artículo

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 la versión para obtener más información.

GitHub Advanced Security para Azure DevOps

Azure Pipelines

GitHub Advanced Security para Azure DevOps

La API de uso de medidores de seguridad avanzada 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 los puntos de conexión existentes de la API de uso de medidores, que se anexan /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

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 impulsan 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 y el costo de un grupo.
  • Escalable: MDP escala a 1000 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 canalizaciones de Azure que usa NodeJS como ejecutor ahora usa 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 canalización de compilación.

Anteriormente, se requería el Edit build pipeline permiso para crear o editar una canalización. Esto supone un riesgo de seguridad, ya que permite a todos los usuarios crear canalizaciones para editar también canalizaciones que no crearon. 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 una canalización YAML; solo protege las propiedades de la canalización para editarlas.

En el caso de los nuevos proyectos, los usuarios y grupos con el Edit build pipeline permiso también tendrán el Create build pipeline permiso . 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 admitir este caso, tenemos la comprobación de bloqueo exclusivo.

Se produce una situación similar cuando solo una ejecución de canalización debe acceder a una fase 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 de proxy, como un entorno, y colocar la comprobació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 fase. Si tiene una fase con un identificador y especifica su lockBehavior propiedad, se crea automáticamente un bloqueo para esa fase. El sequential comportamiento sigue siendo coherente para los bloqueos de nivel de recurso y de nivel de fase. Sin embargo, el runLatest comportamiento difiere, ya que solo cancela runLatest las compilaciones de la misma rama, no para todas las ramas de la canalización.

Información de plantilla en ejecuciones de canalización

Hemos actualizado pipelines Runs - Get REST API con información sobre las plantillas extendidas e incluidas en una ejecución 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 de 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 característica, debe agregar la trigger: manual propiedad a una fase.

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 esta canalización, 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 fases desencadenadas manualmente para ejecutarse.

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.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de 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