Artículo
01/31/2019

Número especial de Connect(); de 2018

Volumen 33, número 13

Azure: Implementación correcta del código con Azure Pipelines

Por Micheal Learned; de 2018

Las aplicaciones modernas son sistemas cada vez más complejos que implican varias pilas de tecnología y servicios nativos de nube. La coordinación de la canalización de versión automatizada de estos sistemas puede resultar complicada. Azure Pipelines ofrece servicios de integración continua (CI) y entrega continua (CD) eficaces y fáciles de usar que le permiten compilar y probar su aplicación y, a continuación, implementarla en los destinos previstos. En este artículo, ofreceremos una introducción a los conceptos clave de Azure Pipelines y describiremos escenarios de implementación para varios servicios de Azure. También recorreremos un escenario detallado para crear una canalización para una aplicación de .NET Core dirigida a los contenedores de Docker de Azure Kubernetes Service (AKS). Por último, le mostraremos la última generación de CI/CD, en que la canalización YAML se configura como parte del código.

Azure Pipelines proporciona flexibilidad para configurar los flujos de trabajo de compilación y lanzamiento. Puede elegir entre varios proveedores de control de versiones, como GitHub, Azure Repos, Bitbucket y Subversion. Se admiten la mayoría de lenguajes y marcos de trabajo de la aplicación, como .NET, Java, JavaScript, Python, PHP, Ruby, Xcode, C++ y Go. Puede crear canalizaciones que se implementen en cualquier parte; por ejemplo, cualquier proveedor de nube o destino de implementación local. Puede usar cualquier repositorio de administración de paquetes, como NuGet, npm y Maven para producir y consumir paquetes. Azure Pipelines le permite configurar y personalizar la solución de CI/CD para que se ajuste a prácticamente cualquier escenario. Las tareas de canalización integrada, las tareas de terceros, las tareas personalizadas y los scripts de Bash y PowerShell basados en archivos o insertados le ayudan a crear flujos de trabajo para sus canalizaciones. Las plantillas proporcionan una manera fácil de agrupar rápidamente y volver a usar un conjunto de tareas.

Conceptos clave de Azure Pipelines

En Azure Pipelines, define flujos de trabajo de compilación (CI) y lanzamiento (CD) para las aplicaciones. Estos flujos de trabajo proporcionan un marco para coordinar y automatizar las canalizaciones de versión. Un escenario típico es una canalización de compilación de CI que extrae código del repositorio de control de versiones, compila el código, ejecuta pruebas y otros procesos de análisis y, finalmente, publica artefactos, como archivos, archivos binarios y archivos ejecutables. Una canalización de versión de CD se desencadena automáticamente y usa los artefactos publicados como la carga útil de implementación para entornos de producción y pruebas. Azure Pipelines le permite crear canalizaciones de CI/CD simples o complejas para implementar sus aplicaciones en una amplia gama de destinos de implementación, incluidos varios servicios de Azure, como servidores web y bases de datos. Se definen las distintas etapas de una canalización de versión; por ejemplo, desarrollo, control de calidad y producción. Es importante tener en cuenta que las canalizaciones de compilación y versión son flexibles, así que puede usarlas para definir prácticamente cualquier flujo de trabajo que quiera.

Los agentes son máquinas (o contenedores) Windows, Linux y macOS que ejecutan los trabajos en las canalizaciones de compilación y versión. Puede instalar y autohospedar sus agentes en máquinas virtuales físicas o virtuales (VM) en un entorno local o en la nube (por ejemplo, Azure). O bien, para ahorrar tiempo, puede usar agentes de Linux, macOS y Windows hospedados por Microsoft. Para proyectos de código abierto, proporcionamos hasta 10 trabajos paralelos hospedados por Microsoft de forma gratuita (consulte los vínculos al final de este artículo para obtener más información).

Las tareas de compilación y versión son los pilares básicos de las canalizaciones. Son scripts empaquetados que hacen el trabajo en la canalización. Azure Pipelines incluye muchas tareas comunes para realizar acciones para compilar, probar, empaquetar e implementar código. Puede personalizar totalmente el proceso con las tareas que admiten scripts de Bash, PowerShell y Python basados en archivos o insertados. Incluso puede ejecutar scripts de archivos por lotes de Windows. Puede usar las tareas que proporciona Azure Pipelines, aprovechar las tareas de terceros de Visual Studio Marketplace y, si es necesario, crear sus propias tareas personalizadas.

Las plantillas de compilación y versión proporcionan patrones reutilizables que le ayudarán a configurar rápidamente CI/CD para escenarios comunes, como compilar una aplicación para Android o implementar una aplicación web de Azure. Una plantilla es, básicamente, un conjunto predefinido de tareas con parámetros preestablecidos para satisfacer las necesidades de los tipos de aplicaciones y los destinos comunes. Puede personalizar las plantillas e incluso colocar sus flujos de trabajo personalizados en plantillas reutilizables para satisfacer las necesidades específicas de su organización.

Las conexiones de servicio proporcionan un mecanismo seguro para conectar servicios externos a tareas de Azure Pipelines. Estos servicios externos pueden incluir suscripciones a Azure, Jenkins u otros sistemas de CI, y servicios remotos como servidores de archivos, entre otros. Un escenario típico es crear una conexión de servicio de Azure Resource Manager (ARM) para permitir que Azure Pipelines implemente sus aplicaciones en varios destinos de servicio de Azure, como Web Apps, Azure Virtual Machines, Azure SQL Database o cualquier otro recurso de sus suscripciones de Azure.

Destinos de implementación de Azure

Azure proporciona una variedad de servicios que actúan como destinos de implementación para las aplicaciones. Algunos destinos de implementación válidos son App Service, máquinas virtuales Windows o Linux, contenedores y muchos otros servicios de Azure. Los contenedores de Docker se pueden usar con App Service, VM y con Kubernetes mediante AKS.

Las máquinas virtuales (Linux y Windows) son destinos de implementación comunes para una amplia gama de aplicaciones. Azure Pipelines admite VM como destinos de implementación en Azure, en entornos locales o incluso en otros proveedores de nube. Instale y configure un agente de implementación en las VM y, a continuación, podrá enlazar las implementaciones de Azure Pipelines con las VM. Los agentes y Azure Pipelines se comunican mediante cifrado asimétrico y HTTPS para proporcionar un enfoque de implementación seguro. Los grupos de implementación le permiten organizar los servidores que hospedan la aplicación. Cada nodo del grupo de implementación hospeda un agente Azure Pipelines y puede implementar en ellos. Un ejemplo de uso de agentes de implementación es implementar el código de una aplicación web en un grupo de servidores web. También puede instalar agentes en máquinas físicas y usar Azure Pipelines para implementar en ellos con patrones similares.

App Service es un servicio de Azure que le permite hospedar aplicaciones en el lenguaje que prefiera sin tener que administrar la infraestructura. También le permite ejecutar API, back-ends móviles, aplicaciones web y código sin servidor. La aplicación web para contenedores permite ejecutar aplicaciones en contenedores en Windows y Linux. Hay muchas maneras de implementar aplicaciones en App Service; por ejemplo, con Azure Pipelines. Puede usar las plantillas existentes de Azure Pipelines para crear rápidamente una canalización de CD para la aplicación. La tarea de implementación de App Service proporciona una variedad de características estándar, como la implementación en ranuras de App Service específicas, el reemplazo de valores de configuración en el tiempo de implementación y la ejecución de scripts personalizados.

AKS proporciona un servicio de administración de Kubernetes basado en Azure que le permite implementar y administrar fácilmente aplicaciones en contenedores. AKS quita la sobrecarga de administración para administrar la coordinación de contenedores compleja, y simplifica la administración de contenedores al encargarse del mantenimiento y la supervisión de estado. Azure administra patrones de Kubernetes y usted solo debe administrar y pagar los agentes. AKS se integra con Azure Container Registry para proporcionar una solución de contenedores totalmente administrada.

Los servicios y la infraestructura de Azure se pueden implementar con plantillas para proporcionar infraestructura como código (IaC), que ofrece muchas ventajas, como aprovechar el control de versiones, CI/CD y automatizar la implementación de la infraestructura para las aplicaciones. Las plantillas de ARM proporcionan un enfoque JSON declarativo para implementar la infraestructura de Azure. Puede definir redes, grupos de seguridad, equilibradores de carga, AKS y muchos otros componentes de infraestructura de Azure con plantillas de ARM.

Azure Pipelines proporciona compatibilidad para la implementación de plantillas de ARM con la tarea de implementación de grupo de recursos de Azure. La tarea permite crear canalizaciones que aprovechan las plantillas de ARM para implementar servicios de Azure en sus suscripciones. La tarea proporciona varias opciones de configuración útiles, como la capacidad para validar plantillas para evitar errores, implementar en modo incremental para evitar el impacto en los recursos de Azure existentes y controlar la creación o actualización de grupos de recursos existentes.

SQL Server es un destino de implementación de base de datos que se presenta de dos formas en Azure. SQL Server puede autohospedarse, y Azure SQL Database es un servicio de Azure para base de datos como servicio (DBaaS) que le permite usar SQL Server sin tener que administrar la infraestructura. Azure Pipelines permite implementar en ambas formas de SQL Server. SQL Server ofrece varias opciones para implementar cambios de esquema con tareas como compatibilidad con dacpac, ejecución de scripts con la utilidad sqlcmd y uso de servicios de terceros con herramientas de Redgate.

Ejemplo: Implementación de una aplicación de .NET Core en un destino de contenedor de AKS

.NET Core es una plataforma de desarrollo multiplataforma (Windows, Linux y macOS) para la creación de aplicaciones de dispositivo, nube e Internet de las cosas (IoT). Los responsables del mantenimiento y el soporte técnico de .NET Core son Microsoft, RedHat y la comunidad de .NET. AKS es un servicio de Kubernetes administrado para Azure. Kubernetes simplifica el uso de contenedores. Puede crear una canalización de CI/CD con Azure Pipelines destinada a AKS con contenedores de Docker. Las plantillas de ARM se utilizan para representar la infraestructura de Azure, como AKS y un registro de contenedores. Las imágenes de Docker se utilizan para incluir una aplicación web de ASP.NET en un contenedor. Se trata de una canalización moderadamente compleja, así que, para ayudarle a ponerse en marcha rápidamente, encontrará un tutorial detallado que automatiza la creación de la canalización de CI/CD para este escenario en bit.ly/2T9Y0pT.

En este ejemplo, una aplicación web de ASP.NET Core se almacena en Azure Repos. Las plantillas de ARM representan el clúster de AKS y el registro de contenedor. Usar IaC de este modo le permite implementar la infraestructura de Azure junto con la aplicación. De este modo, podrá administrar los recursos de Azure y la aplicación en una sola canalización de CI/CD. La Figura 1 es una vista de las estructuras básicas de Azure Repos.

Figura 1 Aplicación de ASP.NET Core y plantillas de ARM

La canalización de compilación para este escenario contiene varios pasos. Puede asignar etiquetas descriptivas como nombre a las tareas. La Figura 2 muestra un conjunto de tareas para configurar una aplicación de ASP.NET Core en contenedor que tiene como destino un clúster de AKS.

Figura 2 Canalización de compilación con Docker y AKS

Obtener el origen es el primer paso del proceso de compilación. La aplicación de ASP.NET Core y las plantillas de ARM se capturan desde Azure Repos y se envían al agente de compilación. Los agentes hospedados en la nube impiden que tenga que administrar la infraestructura para ejecutar canalizaciones.

Crear una instancia de Azure Container Registry es el siguiente paso del proceso de compilación. El registro almacena y administra imágenes de Docker. En los pasos siguientes, se compila y publica la imagen de Docker, que, en este caso contiene una aplicación de ASP.NET Core. Este paso de compilación usa una tarea de implementación de grupo de recursos de Azure para implementar una plantilla de ARM que representa el registro de contenedor. Esta tarea es un ejemplo de la flexibilidad de Azure Pipelines, ya que permite ejecutar una tarea de implementación para configurar el registro como parte del proceso de compilación. La tarea de implementación de ARM se establece en "modo incremental" de forma predeterminada, de modo que, si el registro de contenedor ya existe, no se volverá a crear en ejecuciones de compilación posteriores.

Las tareas de Docker se usan para generar y publicar imágenes de Docker en el registro de contenedor. Este paso pone la aplicación de ASP.NET Core en contenedores. Usar una infraestructura inmutable con un contenedor portátil para la aplicación permite la implementación del contenedor en una amplia variedad de destinos en Windows, la mayoría de distribuciones de Linux y macOS. En este escenario, el destino del contenedor es AKS en Azure.

Los gráficos de Helm proporcionan el formato de empaquetado para Kubernetes que facilita la definición, creación de versiones e instalación de aplicaciones de Kubernetes. Helm, un administrador de paquetes de Kubernetes, se instala en el agente de compilación con la tarea del instalador de herramientas de Helm. La tarea de empaquetar e implementar gráficos de Helm archiva el gráfico en este paso para que los gráficos de Helm acaben publicados como artefactos de compilación.

Copy ARM templates (Copiar plantillas de ARM), que es una tarea de copia, copia las plantillas en un directorio de almacenamiento provisional en el agente de compilación. Las plantillas de ARM son archivos JSON que representan recursos de Azure. Esta plantilla de ARM representa el recurso de clúster de Kubernetes. Las plantillas de ARM se almacenan Azure Repos, pero también puede usar otro proveedor de control de versiones, como GitHub, para las canalizaciones.

Publicar los artefactos de compilación es una tarea que copia el contenido del directorio de almacenamiento provisional en Azure Pipelines. Puede almacenar los artefactos en un recurso compartido de archivos en alguna parte, pero Azure Pipelines es una opción cómoda que no requiere ninguna configuración adicional. En este caso, los artefactos son las plantillas de ARM y el paquete de Kubernetes que generan los gráficos de Helm.

Una vez ejecutada la canalización de compilación, la canalización de versión consume los artefactos de la canalización de compilación e implementa la solución. La Figura 3 muestra los distintos pasos de la canalización de versión.

Figura 3 Canalización de versión para la aplicación de .NET Core y Kubernetes

La tarea de implementación del grupo de recursos de Azure es el primer paso de la canalización de versión. Esta tarea consume la plantilla de ARM de AKS y es el artefacto que se usa para implementar el clúster de AKS. Los artefactos de la plantilla de ARM están disponibles para esta canalización de versión porque las plantillas se publicaron como artefactos como parte de la ejecución de la canalización de compilación.

Las tareas de PowerShell se pueden usar en cualquier compilación y canalización de versión. Esta tarea de PowerShell usa el comando de registro setvariable para inicializar algunas variables persistentes para que las tareas siguientes de Helm puedan tener acceso a las partes clave de los datos comunes. En este caso, el script obtiene acceso a las salidas de implementación que creó la tarea de implementación de ARM anterior. En concreto, se establecen las variables que se usarán más tarde para el enrutamiento de la aplicación y Application Insights:

$deploymentOutputs=(ConvertFrom-Json '$(deploymentOutputs)')
$applicationRoutingZone=$deploymentOutputs.applicationRoutingZone.value
$aiKey=$deploymentOutputs.aiKey.value
Write-Host "##vso[task.setvariable
  variable=applicationRoutingZone;]$applicationRoutingZone"
Write-Host "##vso[task.setvariable variable=aiKey;]$aiKey"

Las tareas de Helm organizan los últimos tres pasos del proceso de lanzamiento. El instalador de la herramienta Helm garantiza que el agente instala la versión más reciente del administrador de paquetes de Kubernetes, que incluye requisitos previos como Kubectl, la herramienta de línea de comandos para Kubernetes. Se ejecutan los comandos Helm init y Helm upgrade para implementar la aplicación en Kubernetes. Una vez ejecutada la canalización de versión, la aplicación de ASP.NET Core se implementa en un clúster de Kubernetes y está accesible a través de la dirección URL.

Como una opción para empezar a trabajar rápidamente, Azure DevOps Projects permite automatizar la creación de una canalización de CI/CD, como la que se ha descrito antes, especialmente si no está familiarizado con la implementación en servicios de Azure. Use una experiencia basada en asistente desde Azure Portal para elegir entre una variedad de marcos de trabajo de la aplicación y destinos de implementación. En unos pocos pasos sencillos, puede crear una canalización de CI/CD completamente funcional que compile e implemente el código en varios servicios de Azure, como App Service, VM, AKS y SQL Database. DevOps Projects le permite usar su propio código o cualquiera de las diversas aplicaciones de ejemplo proporcionadas. Puede usar DevOps Projects para crear una canalización en Azure Pipelines y, a continuación, usarla como arquitectura de referencia en cuanto a la forma de hacer CI/CD para marcos de trabajo de la aplicación y destinos de implementación de servicios de Azure específicos. También puede personalizar más las canalizaciones. Azure DevOps Projects también crea recursos de Azure adicionales, como Application Insights, para la supervisión y un panel basado en Azure Portal. Encontrará documentación de Azure DevOps Projects en bit.ly/2B7XnpJ.

Configuración como código en una canalización de YAML

En el ejemplo anterior, vimos cómo puede usar Azure Portal para generar una canalización de compilación de un extremo a otro que cree y, a continuación, proporcione artefactos en una canalización de versión. Los tipos de canalizaciones que genera Azure Portal se denominan "canalizaciones de diseñador". Se trata de canalizaciones de arrastrar y colocar. Este año se introdujo un nuevo tipo de canalización que puede definir en el código fuente: una canalización YAML.

Las ventajas más evidentes de una canalización YAML derivan del hecho de que el flujo de trabajo reside en el código. Puede bifurcar, comparar y combinar los cambios de la lógica de negocios. Si esto le parece genial, espere a la próxima vez que alguien cambie la canalización y provoque una interrupción en la compilación o un resultado inesperado. Por difícil que pueda resultar este escenario, le aliviará saber que puede detectar, seguir y corregir el problema igual que cualquier otro error del código.

Si el repositorio contiene un archivo azure-pipelines.yml en el nivel raíz, a continuación, cuando vaya a crear la canalización, el sistema recupera el archivo. Puede bifurcar uno de nuestros repositorios de la aplicación de ejemplo para verlo en acción en aka.ms/get-started-yaml-pipeline. La Figura 4 muestra una canalización YAML de ASP.NET Core básica. Si el repositorio de GitHub aún no tiene un archivo azure-pipelines.yml, cuando cree una canalización nueva, el sistema analizará el código del repositorio y, a continuación, sugerirá el tipo de canalización que necesita, como se muestra en la Figura 5.

Figura 4 Canalización YAML de ASP.NET básica en un repositorio de la aplicación de ejemplo

Figura 5 Azure Pipelines examina el código y sugiere una plantilla para la canalización YAML

Para ayudarle a migrar desde canalizaciones de diseñador y aprender a adaptarlas a YAML, se proporcionan herramientas e información. Cuando edite la canalización de diseñador, seleccione una tarea y, a continuación, seleccione Ver YAML, como se muestra en la Figura 6.

Figura 6 Después de seleccionar una tarea en el diseñador, puede ver el código YAML

En algunos casos, puede usar este fragmento de código directamente. A veces (por ejemplo, si la tarea usa parámetros de proceso, por lo general, generados mediante una plantilla), deberá ajustar manualmente el código YAML.

También hay una extensión de VS Code en versión preliminar en aka.ms/azure-pipelines-vscode. Funciona con un servidor de lenguaje, por si quiere compilar herramientas de enlaces previos a la confirmación. Más información en aka.ms/azure-pipelines-language-server.

Para obtener más información sobre lo que puede hacer con YAML, consulte aka.ms/azure-pipelines-yaml-schema y aka.ms/azure-pipelines-task-reference.

Los scripts son una forma muy común de controlar flujos de trabajo de CI y CD en el código. Las canalizaciones YAML están diseñadas para facilitar al máximo la integración de scripts donde quiera y de la forma más portable posible. Cuando esté al día en YAML, probablemente verá que hay enfoques centrados en tareas y en scripts. La decisión sobre qué enfoque usar es una cuestión de preferencias personales.

Para tareas sencillas, puede usar un script multiplataforma genérico:

steps:
- script: echo This is pipeline $(System.DefinitionID)

Puede ejecutar explícitamente un script de Bash o PowerShell. Los scripts de Bash tienen la ventaja de que se pueden ejecutar en varias plataformas. Consulte la Figura 7 para obtener un ejemplo. Para obtener más información, consulte aka.ms/cross-platform-scripts.

Figura 7 Canalización YAML con un script de Bash que se puede ejecutar en Linux, macOS y agentes de Windows

trigger:
  batch: true
  branches:
    include:
    - master
steps:
- bash: |
   echo "Hello world from $AGENT_NAME running on $AGENT_OS"
   case $BUILD_REASON in
    "Manual") echo "$BUILD_REQUESTEDFOR manually queued the build." ;;
    "IndividualCI") echo "This is a CI build for $BUILD_REQUESTEDFOR." ;;
    "BatchedCI") echo "This is a batched CI build for $BUILD_REQUESTEDFOR." ;;
    *) $BUILD_REASON ;;
    esac
  displayName: Hello world

Si el equipo no necesita las opciones de fases y aprobación que proporciona una canalización de versión de diseñador, puede realizar la compilación, las pruebas y la implementación desde una única canalización YAML, tal como se muestra en la Figura 8.

Figura 8 Compilar, probar e implementar desde una canalización YAML que se encuentra en el código base

# Build, test and deploy in a YAML pipeline
pool:
  vmImage: 'ubuntu-16.04'
  # replace the hosted Ubuntu pool above with the Windows pool below if
  # you want to deploy to a Windows web app
  # vmImage: 'vs2017-win2016'
variables:
  buildConfiguration: 'Release'
trigger:
- master
steps:
- script: |
    dotnet build --configuration $(buildConfiguration)
    dotnet test dotnetcore-tests --configuration $(buildConfiguration) --logger trx
- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration)
      --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True
- task: AzureRmWebAppDeployment@3
  inputs:
    azureSubscription: 'YourSubscription'
    WebAppName: 'your-webapp'
    Package: $(Build.ArtifactStagingDirectory)/**/*.zip
    # Uncomment the attribute below if you are deploying to a Windows Web app
    # TakeAppOfflineFlag: true

Este ejemplo funciona para aplicaciones web para Windows y Linux. Para adaptarlo a Windows, agregue y quite los comentarios correspondientes para cambiar el grupo hospedado por Microsoft que use y para definir el parámetro TakeAppOfflineFlag como true para desconectar la aplicación antes de la implementación a fin de evitar un error de archivo en uso en el archivo .DLL de la aplicación web.

Las conexiones de servicio (anteriormente, "puntos de conexión") pueden ser una parte del proceso difícil de configurar. Los parámetros siguientes permiten especificar el destino de la aplicación web:

azureSubscription: 'YourSubscription'

WebAppName: 'your-webapp'

Estos parámetros hacen referencia a campos de una conexión de servicio de Azure Resource Manager. Consulte aka.ms/azure-pipeline-service-connection.

Resumen

Puede empezar a usar Azure Pipelines de forma gratuita. Azure Pipelines proporciona distintos niveles de uso gratuito para un determinado número de minutos mensuales y trabajos paralelos. Se pueden adquirir minutos y trabajos adicionales por una cuota mensual. Los proyectos de código abierto reciben varios trabajos paralelos gratuitos. Puede encontrar más información sobre los precios de Azure Pipelines en aka.ms/azure-pipelines-pricing.

Implementar aplicaciones en Azure con Azure Pipelines le permite crear patrones de CI/CD reutilizables y automatizar de forma confiable cada paso de las implementaciones. Puede crear canalizaciones de varias maneras, usar flujos de trabajo simples o complejos, e implementar de forma segura en una amplia gama de destinos de implementación. Azure DevOps Projects proporciona automatización para Azure Pipelines para ayudarle a empezar a trabajar rápidamente con la implementación de sus aplicaciones en servicios de Azure. Las canalizaciones YAML permiten crear patrones de configuración como código que ofrecen muchas ventajas. Para obtener más información, consulte aka.ms/sign-up-for-azure-pipelines, aka.ms/azure-devops-project y aka.ms/learn-azure-pipelines.

Micheal Learned lleva más de 20 años trabajando en proyectos de ingeniería de software dentro y fuera de Microsoft. Learned dedica su tiempo a su familia y amigos, y a todo lo relacionado con DevOps y la nube. Puede ponerse en contacto con él a través de Twitter: @mlhoop.

Andy Lewis escribe sobre diversos aspectos de Azure DevOps, como el control de versiones y las canalizaciones de CI/CD. En Microsoft, ha trabajado para los clientes desde la división de Windows, Office y desarrollo. Lewis ha diseñado y desarrollado contenido, elementos multimedia y aplicaciones para una amplia gama de públicos en IBM, Borland, Intuit, SAS Institute y Microsoft.

Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Jason Conner, Matt Cooper
Jason Conner es ingeniero de DevOps y trabaja a las afueras de Illinois en el desarrollo de .NET, los macrodatos y Azure.

Matt Cooper es director de programas, y trabaja en Raleigh, Carolina del Norte, en la plataforma Azure Pipelines, los agentes y el analizador YAML.

Comente este artículo en el foro de MSDN Magazine