Agosto de 2016

Volumen 31, número 8

DevOps: aplicación de DevOps a un proyecto de desarrollo de software

Por Willy-Peter Schaub, Wouter de Kort y Mattias Sköld | Agosto de 2016

"DevOps es la unión de personas, procesos y productos para permitir la entrega continua de valor a nuestros usuarios finales."—Donovan Brown en el libro "DevOps on the Microsoft Stack" (Wouter de Kort, 2016).

Cada viaje de DevOps comienza con una idea que quiere convertir en una solución basada en una cultura de aprendizaje y entrega continua de valor. El objetivo de este artículo es compartir el aprendizaje recabado durante la exploración de la implementación de una canalización de versiones automatizada para nuestros entornos de desarrollo, pruebas de aceptación del usuario y producción. Le guiaremos por una canalización de versiones automatizada, que puede adoptar "tal cual" o desarrollar para satisfacer sus requisitos.

Así, ¿qué nos llevó a adoptar DevOps? Al conocer en profundidad el "por qué" (objetivo), el "qué" (características) y el "cómo" (tecnología y código) de la compilación de extensiones, surgió la necesidad de una referencia cultural y un entorno que nos permitieran compilar, probar, lanzar y supervisar la familia de extensiones que evolucionaba y crecía rápidamente. La promesa de DevOps nos animó a explorar y adoptar los procesos y las herramientas que nos ofrecía Visual Studio Team Services (Team Services para abreviar). Nuestros equipos autoorganizados y autónomos estaban facultados para desarrollar una referencia cultural y una canalización que redujeran los ciclos de lanzamiento de días de trabajo manual intensivo, caótico y propenso a errores a solo unos minutos. Una historia similar y la explicación de la canalización se explican en otro artículo de esta edición ("Del código al cliente: exploración de DevOps móvil").

Si no está familiarizado con los Rangers, formamos una comunidad de ingenieros internos y externos que trabajan con el grupo de productos para proporcionar orientación profesional, experiencia práctica y soluciones de relleno de lagunas para la comunidad de desarrolladores. Es esto último, las lagunas, lo que nos fascina e impulsa nuestro trabajo con las extensiones.

Las extensiones proporcionan una experiencia de integración y extensibilidad para Team Services y Team Foundation Server (TFS). Los puntos de extensión incluyen el formulario de elementos de trabajo, las tareas de compilación y versión, los widgets de panel, las acciones de menú, Agile y otros concentradores. Estos permiten proporcionar soluciones de relleno de lagunas, que se integran con el producto y lo mejoran, además de mejorar la experiencia de usuario y la productividad.

Una extensión típica está formada por un conjunto de archivos JavaScript, HTML y CSS, como se muestra en el blog de 2015 de Willy P. Schaub, "Extensions 101—Attempting to Visualize the Main Processing Flow" (Extensiones 101: intentar visualizar el flujo de procesamiento principal, bit.ly/28Yfj7A). Uno o más archivos de manifiesto JSON describen la información básica, los archivos incluidos con la extensión y las contribuciones que esta proporciona. Consulte la muestra de extensión Folder Management de código abierto, que permite crear rápidamente una carpeta en los repositorios de código fuente de Team Services de la Web sin clonar el repositorio localmente ni instalar herramientas adicionales.

Cada extensión se describe en un manifiesto basado en JSON, denominado vss-extension.json, de forma predeterminada. Por motivos de coherencia, hemos optado por basar todas las extensiones futuras en la plantilla de proyecto de Team Services y usar TypeScript para todo nuestro código JavaScript. El Administrador de paquetes de nodos (NPM) se usa para descargar dependencias externas, como la biblioteca de términos, que es necesaria para TypeScript IntelliSense. Aprovechamos la capacidad de NPM para definir un conjunto básico de scripts para inicializar el entorno de desarrollo. Una dosis de coherencia garantiza que los miembros del equipo puedan moverse fácilmente entre equipos y que los problemas se puedan investigar y resolver mucho más fácilmente. Permite ciclos más cortos.

Publicación manual de una extensión

Si clona el repositorio Folder Management en su máquina de desarrollo local, podrá empaquetar y publicar la extensión rápidamente en su cuenta del Marketplace manualmente. Del siguiente modo:

• Use NPM Scripts Task Runner (bit.ly/28Qmktu) o ejecute los comandos desde la línea de comandos.
• Abra la solución y ejecute la tarea de instalación: npm run setup. Esta acción descargará los paquetes de NPM, inicializará los términos necesarios para TypeScript y colocará sus dependencias externas en la ubicación correcta.
• Use Visual Studio para compilar los archivos TypeScript y generar el JavaScript de salida.
• Ejecute la tarea de empaquetado NPM para crear un archivo VSIX de salida basado en el manifiesto del proyecto.
• Cargue el archivo VSIX generado en el Marketplace o ejecute npm run publish para empaquetar y publicar automáticamente su extensión.

Veamos primero una introducción. Team Services está formado por cuentas aisladas. El Marketplace es global y está formado por publicadores. Además, su creador y administrador es el publicador de la galería (usted). Una extensión se comparte como privada y se comparte explícitamente con las cuentas de Team Services. Como alternativa, una extensión se puede publicar como pública una vez validada, de forma que sea visible para todo el mundo. Se recomienda encarecidamente no publicar nunca esta ni otras extensiones de muestra como públicas a fin de evitar una experiencia de usuario confusa y potencialmente negativa.

Para publicar su extensión, asegúrese de que el campo del publicador en el manifiesto coincide con el nombre del publicador del Marketplace. Si el publicador no está comprobado por Microsoft, solo podrá publicar una extensión como privada. Para publicar su extensión desde la línea de comandos o NPM Task Runner, también necesitará un token de acceso personal que conceda permiso para administrar el publicador del Marketplace. Consulte el artículo "Publish an Extension to the Marketplace" (Publicar una extensión en el Marketplace, bit.ly/28SDsOM), para obtener más información.

Canalización de compilación y versiones automatizada

A medida que la familia de extensiones y revisiones crece, estos pasos manuales aparentemente simples pronto se complicarán y tenderán a generar errores. Por lo tanto, empezamos trabajando en la canalización automatizada, con scripts y tareas de compilación para automatizar los pasos manuales.

Puede usar las tareas de compilación de Windows PowerShell y de la línea de comandos para empaquetar el manifiesto de la extensión y revisar el número de versión, como se muestra en la Figura 1. Esto se describe con más detalle en el artículo "Our First Steps of Embracing DevOps When Building Visual Studio Team Services Extensions" (Primeros pasos de la adopción de DevOps al compilar extensiones de Visual Studio Team Services, aka.ms/t0wfh6), simple y eficaz.

Figura 1 Tarea de compilación de Windows PowerShell (superior) y tarea de compilación de la línea de comandos (inferior)

De forma alternativa, puede usar Build and Release Tasks for Extensions para optimizar el proceso de compilación y versión. El resto de este artículo se basa en esta extensión.

Veamos como hemos usado Build and Release Tasks for Extensions e implementado un proyecto para todos los demás proyectos de extensiones. Cada extensión comienza su viaje en una cuenta de Team Services aislada, que es la primera fase de la implementación de una extensión. Release Management se refiere a estas fases como entornos; por lo tanto, lo denominamos el entorno de desarrollo (DEV). Luego, se somete a una serie de validaciones de diseño, codificación, características, experiencia de usuario y rendimiento en un entorno independiente de aceptación del usuario y el propietario del producto (BETA). De manera similar a lo que sucede en el entorno de desarrollo, se trata de una cuenta de Team Services aislada y la segunda fase de la implementación de la extensión. Cuando una extensión cumple con nuestra definición de listo (bit.ly/28PLYyi), se implementa en el Marketplace y es visible para todo el mundo. Es posible que reconozca las fases DEV → BETA → PROD de la canalización de versiones tomando forma.

Para preparar el proyecto de extensión para la canalización automatizada, se recomiendan los cambios siguientes en el manifiesto de la extensión, como se muestra en la Figura 2:

• Establecer la versión en 0.0.0 y el publicador en una cadena vacía ("")
• Marcar la extensión como private (public: false)
• Quitar el atributo galleryFlags

Figura 2 Extracto del archivo de manifiesto

{  "manifestVersion": 1,
  "id": "FolderManagement",
  "version": "0.0.0",
  "publisher": "",
  "name": "Folder Management",
  "description": "Quickly create a folder in your Visual Studio Team
    Services source repositories from the web. No need to clone the
    repository locally or install extra tools.",
  "public": false,
  "icons": {
    "default": "images/VSO-Folder-196x.png"
  },
  "categories": [
    "Code"
  ],
  snipped rest of manifest file ...
}

Estos valores se actualizarán durante la implementación de la versión y los valores predeterminados garantizarán que la extensión no se implemente ni se publique por accidente.

 La adopción de una convención de nomenclatura coherente simplificará la trazabilidad en los distintos entornos. Si, por ejemplo, sufija el identificador con el entorno durante la versión, FolderManagementBeta sería la extensión Folder Management que se ejecuta en el entorno BETA.

La integración continua (CI) es una práctica que le permite tener una compilación preparada para producción del código más reciente en un repositorio de control de código fuente (bit.ly/28OtZ8K). Esto se lleva a cabo mediante la compilación automatizada y las pruebas se ejecutan con cada confirmación.

Nuestros proyectos de extensión suelen almacenarse en un repositorio GIT hospedado por Team Services, o en GitHub para proyectos de código abierto, como la extensión Folder Management. La canalización comienza con una definición de compilación que se desencadena con cada confirmación realizada en el repositorio y, después, compila el paquete de extensión de VSIX y desencadena la definición de versión para implementarla en los entornos DEV, BETA y PROD.

Como se muestra en la Figura 3, asegúrese de habilitar la integración continua y, de manera opcional, agrupar por lotes los cambios para reducir el número de compilaciones en ejecución.

Figura 3 Desencadenador de compilaciones

El lector astuto puede haber observado que la compilación de CI solo genera un paquete VSIX y no copia los archivos de origen de la extensión. El motivo por el que lo hacemos es uno de los principios básicos de una canalización de entrega: compilar una vez y solo una. En lugar de compilar y empaquetar los archivos de extensión en cada paso de la implementación, solo los empaquetamos una vez al principio de la canalización con distintas configuraciones por entorno. Lo hacemos para estar completamente seguros de implementar exactamente la misma extensión en cada uno de los distintos entornos. 

El control de versiones de la extensión y las tareas de compilación es importante. En Team Services, la versión más reciente es la ganadora. Si instala una versión pública y una versión beta de la misma extensión en una cuenta de Team Services, debe quedar claro qué versión se activará.

¿Cuáles son las opciones para el control de versiones? Las herramientas para desarrolladores de Team Services permiten usar cualquier número de versión de tres partes como extensión. Ante todo, por simplicidad y para ofrecer una trazabilidad transparente, hemos decidido usar Compilación.NúmeroDeCompilación como número de versión, como se muestra en la Figura 4.

Figura 4 Formato del número de compilación

De forma alternativa, puede usar la tarea Query Extension Version, que proporciona mayor control sobre los números de versión que publica. Para ello, toma la versión actual del Marketplace e implementa una parte específica cada vez que se publica la extensión. Al mismo tiempo que reduce la trazabilidad entre la versión del Marketplace y los artefactos de Team Services, proporciona una numeración secuencial mejor para los clientes del Marketplace.

¿Qué hay de las pruebas automáticas? La compilación de CI también es un buen lugar para ejecutar elementos, tales como pruebas unitarias. La extensión Folder Management no usa pruebas unitarias porque toda la lógica destina las llamadas a las API de REST de Team Services. Otras extensiones, como Countdown Widget (bit.ly/28PTCag), incluyen pruebas unitarias que validan la lógica para calcular la diferencia horaria. Estas pruebas unitarias se ejecutan como parte de la compilación. Otras pruebas automatizadas que queremos agregar en el futuro son las pruebas web de Selenium. Esto no solo nos permite ejecutar pruebas unitarias, sino también automatizar las pruebas de IU.

En la Figura 5 se muestran los pasos de compilación. Las dependencias NPM se instalan con la instalación de npm (1) y el script de instalación se procesa con la tareas npm exec. Como alternativa, se puede usar NuGet y la actividad de restauración de NuGet. A continuación, la tarea de compilación de Visual Studio (2) compila la solución, seguida de la tarea de empaquetado de extensión (3), que produce el paquete de extensión de VSIX.

Figura 5 Definición de compilación

De manera opcional, puede configurar los identificadores del publicador y la extensión, la etiqueta y el nombre para reemplazar los valores del manifiesto. La canalización solo configura el número de versión (4) como parte de la compilación y lo establece en el número de compilación para garantizar que se pueda realizar el seguimiento de todas las instancias de la canalización, así como identificarlas de manera exclusiva.

¿Cuál es la finalidad de la tarea script de PowerShell? En el momento de redactar este documento, el siguiente script era necesario para extraer la información de versión (futuras versiones de las herramientas de desarrollador de extensiones; las tareas de compilación [bit.ly/28R0oMh] convertirán el script en obsoleto):

$bldVerD =("$env:BUILD_BUILDNUMBER").replace("$env:BUILD_DEFINITIONNAME","").Trim();
Write-Verbose "Extracted buildVersion $bldVer";
Write-Host "##vso[task.setvariable variable=ExtensionVersion;]$bldVer"

La entrega continua es la capacidad de usar la salida de CI y de compilar e implementar la nueva compilación correcta conocida en uno o varios entornos automáticamente (bit.ly/28PWsfk). Existe una diferencia sutil entre la entrada continua y la implementación continua. La última es para un único entorno. Un equipo pequeño podría implementar solo la implementación continua porque cada cambio pasa directamente a producción. La entrega continua mueve el código entre distintos entornos y finaliza en producción, lo que puede incluir aprobaciones y pruebas de rendimiento, carga e IU automatizadas durante el proceso.

La implementación en el entorno DEV es un proceso totalmente automatizado que se produce con frecuencia. Esto significa que cada compilación de CI correcta se implementa en DEV sin realizar pasos manuales. Como se muestra en la Figura 6, después de la correcta implementación de DEV, se solicita una aprobación previa antes de la implementación en el entorno BETA. El jefe del proyecto o el administrador de programas aprueban esta fase. Finalmente, existe un paso de aprobación previa para la versión pública para producción. Esta deben aprobarla el jefe del proyecto y el administrador de programas. Por una cuestión de simplicidad, decidimos usar solo los pasos de aprobación previa y automatizar el paso de aprobación posterior, porque no tenemos ningún motivo para aprobar un paso de implementación posterior y, después, no realizar la implementación en el siguiente entorno.

Figura 6 Desencadenador de versiones

En la Figura 7 se muestra la definición de versión , que implementa el paquete de extensión de VSIX en tres entornos. El primer entorno, DEV (1), es propiedad del equipo que compila la extensión, que también lo administra. La extensión se implementa como privada y se comparte con una cuenta de espacio aislado de desarrollo.

Figura 7 Definición de versión

Una vez que la versión se ha probado y aprobado, la implementación continúa en el segundo entorno, BETA (2). La extensión se sigue implementando como privada y se comparte con una cuenta de espacio aislado de aceptación del usuario.

Una vez que las pruebas de aceptación del usuario se completan y aprueban, la implementación continúa con el cambio del publicador, la definición de la visibilidad en pública y la implementación de la extensión en el Marketplace (3).

La tarea Publish Extension (4) es la esencia del proceso de implementación y el ingrediente secreto de la canalización. Esta tarea actualiza el archivo VSIX, para lo cual descomprime el contenido, actualiza los valores de configuración y comprime todos los archivos. A continuación, la tarea realiza su implementación en la cuenta de publicador del Marketplace configurada, como el publicador alm-rangers configurado para el entorno Beta, tal como se muestra.

La etiqueta de Extension ID (5) y el nombre se reemplazan para garantizar que tenemos una instancia única de la extensión ejecutándose en cada entorno, que las extensiones Dev y Beta se comparten automáticamente con las cuentas de Team Services de desarrollo y pruebas de aceptación del usuario, y que las versiones DEV y BETA son privadas.

Se requiere un token de acceso personal (6) para publicar una extensión mediante la tarea Publish Extension o la línea de comandos. Para almacenar el token de forma segura, puede crear una conexión de servicio de Team Services al Marketplace. La conexión define un par clave-valor donde la clave es el nombre de la conexión y el valor es el token de acceso.

Otras tareas que puede explorar incluyen:

• Query Extension Version: busca en el Marketplace el número de versión de una extensión publicada. La versión se puede almacenar en una variable y la canalización la puede usar para crear una versión nueva, por ejemplo, incrementando el número de versión principal, secundaria o de revisión.
• Install Extension: implementa una extensión en el Marketplace sin instalarla en una cuenta.
• Share Extensions: comparte una extensión privada en las cuentas especificadas.

En este punto, la canalización compila, empaqueta y actualiza de manera coherente la extensión y, lo más importante, protege los entornos de errores comunes. Ejemplos de errores de compilación son cuando se producen errores en el código TypeScript o si faltan archivos. La implementación falla cuando el archivo VSIX no es válido, si el acceso a los entornos está restringido o si uno de los aprobadores rechaza la versión.

Resumen

Ahora que ha automatizado la canalización de compilación y versión, puede acelerar sus procesos de desarrollo, reducir los errores derivados de la intervención humana y, lo más importante, desarrollar sus soluciones, además de mejorar de forma continua la reflexión, la medición y el aprendizaje.

Pero ese tema lo dejaremos para otro día.

La canalización de CI y CD automatizada ha reducido de días a minutos los ciclos de nuestros procesos manuales y propensos a errores de compilación y versión de extensiones. Es una experiencia estimulante que permite a nuestro equipo de desarrollo destinar tiempo y esfuerzos a aquello que es verdaderamente importante.

Las prácticas de DevOps aquí ilustradas se pueden aplicar también a sus propios proyectos. Team Services permite DevOps para cualquier idioma y cualquier plataforma (local, móvil, en la nube y en la nube híbrida). Con características que permiten planear, crear versiones, compilar, implementar y supervisar su aplicación, Team Services tiene todo lo que necesita para convertir una idea en un componente de software funcional. Con esta información, nos complace ver las extensiones que la comunidad crea para mejorar las funcionalidades de Team Services mientras se embarca en su viaje de DevOps.

Recursos de DevOps

• Build and Release Tasks for Extensions (Tareas de compilación y versión de extensiones) aka.ms/tasksforext
• La extensión Folder Management también está disponible como código de ejemplo en GitHub aka.ms/foldermanagement
• Library of tooling and guidance solutions (Biblioteca de herramientas y soluciones de orientación) aka.ms/vsarsolutions
• Overview of extensions for Visual Studio Team Services (Descripción general de las extensiones de Visual Studio Team Services) bit.ly/293YEOm
• Visual Studio Marketplace es un lugar donde buscar extensiones, herramientas, productos y servicios para Visual Studio, Visual Studio Team Services, Visual Studio Code y Team Foundation Server marketplace.visualstudio.com
• La plantilla de proyecto de Visual Studio Team Services contiene todo lo que necesita para crear una extensión de Visual Studio Team Services o una tarea de compilación o versión personalizada.aka.ms/extensiontemplate
• What is DevOps? (¿Qué es DevOps?)aka.ms/whatisdevops

Willy-Peter Schaub es administrador en jefe de programas de los ALM Rangers de Visual Studio en el Centro de excelencia de Microsoft en Canadá. Podrá encontrar su blog en blogs.msdn.com/b/willy-peter_schaub y seguirlo en Twitter: @wpschaub.

Wouter de Kort es el consultor principal de Microsoft en Ordina (Países Bajos), donde ayuda a las empresas a mantenerse a la vanguardia del desarrollo de software. Puede consultar su blog en wouterdekort.com. Puede seguirlo en Twitter: @wouterdekort.

Mattias Sköld es instructor de DevOps/ALM en Sogeti (Suecia), donde ayuda a los clientes a mejorar sus prácticas de software y dirige la adopción de las prácticas de ALM/DevOps internamente en Sogeti. Puede consultar su blog en mskold.blogspot.com y seguirlo en Twitter: @mattiasskold.

Gracias a los siguientes expertos técnicos de Microsoft por revisar este artículo: Donovan Brown, Jess Houwing y Will Smythe