He sido un gran admirador de Azure DevOps desde sus primeros días, cuando todavía se llamaba Visual Studio Online. Lo uso para fines profesionales y personales,
y lo recomiendo a mis clientes de consultoría.
Sin embargo, no importa cuánto elogie esta plataforma, a menudo es difícil convencer a los desarrolladores de Node o Java de que Azure DevOps funcionará bien con sus proyectos, no peor que para .NET. Independientemente de la cantidad de demostraciones y presentaciones que refuten los prejuicios, en cualquier grupo hay personas que creen firmemente que ADO no es adecuado para ellos, porque es una "herramienta de Microsoft".
Dejando a un lado el debate filosófico, puedo explicar la mayor parte de la resistencia por la falta de comprensión de cómo evolucionó Azure DevOps de su predecesor Team Foundation Services (TFS), y se convirtió en la mejor caja de herramientas capaz de soportar proyectos de cualquier tamaño "en cualquier idioma y cualquier plataforma ". La pregunta es, ¿cómo puedo probar de manera concluyente esto de una vez por todas?
Jugué un poco con esta idea, y luego me di cuenta. La prueba debe hacerse sin crear otra demostración de CI / CD para los microservicios SpringBoot implementados para Kubernetes en AWS; debe hacerse con un enfoque más excéntrico.
Y ahora algo completamente diferente
¿Qué sucede si dejamos de centrarnos en los lenguajes y plataformas modernos y avanzamos hace 30 años para ver si las herramientas modernas y ADO pueden usarse para desarrollar, construir, dividir en módulos e implementar un programa escrito para una plataforma de computadora de 8 bits?
Como en el caso de otras demostraciones para ADO que creé en el pasado, quería mostrar un producto completamente terminado, desde editar el código, verificarlo, etc. hasta el entorno en vivo en el que puede ver los cambios.
En teoría, todo esto sonaba bien, pero la verdadera pregunta era: ¿por dónde empezar? Obviamente, esta no era una situación en la que pudiera ejecutar StackOverflow en busca de ejemplos anteriores. Sin embargo, habiendo discutido la idea con amigos y colegas (todos decidieron que me había mudado), comencé a elaborar mi idea.
Decidí que el programa de demostración debería escribirse en código de máquina de 8 bits para Commodore 64 usando el editor de código VS. La fuente será procesada por el repositorio de Git en ADO, y la canalización de CI / CD será responsable de las compilaciones, los módulos y la implementación en Azure. Ya comencé a sospechar que mis amigos tenían razón, y mi techo ya se había ido, pero esta idea parecía un desafío interesante.
Elección del editor
Todos conocen el dicho acerca de elegir la herramienta adecuada para un trabajo en particular. Esto se aplica al trabajo doméstico, reparación de automóviles y escritura de códigos.
Como desarrollador de .NET, paso la mayor parte de mi tiempo en Visual Studio 2017. Si necesito cambiar a un proyecto Java o escribir programas nativos de Android, lanzo IntelliJ o Android Studio respectivamente. ¿Qué editor debo usar para el código de máquina C64?
¿Quiere, lo crea o no, pero hoy en día hay varios buenos editores adecuados para escribir CBM? Jugué con algunos de ellos, pero en realidad quería usar Visual Studio Code. Utilicé VS Code para mis otros proyectos, y me pareció muy flexible, cómodo, y la presencia de integración integrada con git fue una buena adición.
La desventaja de esta solución era que tendría que sacrificar el resaltado de sintaxis en el ensamblador 6510, y simplemente miraría el texto negro sobre un fondo blanco. Esta situación no corresponde a mi declaración sobre la "herramienta correcta".
De repente, decidí ir a Visual Studio Marketplace y ver si ya hay alguna extensión para VS Code que sea adecuada para resolver mi problema. Me sorprendió gratamente encontrar allí varias extensiones diseñadas para trabajar en ensamblador. Desafortunadamente, ninguno de ellos fue encarcelado por el ensamblador cruzado de ACME que seleccioné para el proyecto.
Esto no me detuvo y, al no querer revivir los aspectos monocromáticos del desarrollo de los años 80, me enterré en la documentación sobre la creación de extensiones para VS Code. Unos días después, publiqué con gusto la primera versión de la extensión para Visual Studio Marketplace.
Y este ejercicio resultó ser más útil de lo que parecía inicialmente.
En un momento, no me enfoqué en escribir programas en ensamblador. Varias veces intenté estudiarlo, pero generalmente me sentía aburrido o irritado, y pasé a otra cosa. Después de crear el complemento, no solo aprendí sobre la mecánica de crear extensiones para VS Code, sino que también adquirí una buena comprensión de la oscura sintaxis y los códigos de operación.
Armado con un editor adecuado y algunos viejos libros de programación de los años 80, comencé a escribir código. Muy rápidamente obtuve un programa de trabajo que importaba un archivo de música en formato SID y reproducía una versión de 8 bits de Beatles When I'm 64 (esta es una vieja broma de los usuarios de Commodore, pero parece ser adecuada para este proyecto).
Hasta ahora, he compilado y probado el programa en una computadora portátil. El código fuente se confirmó en el repositorio git, por lo que el siguiente paso fue la necesidad de crear una compilación para la Integración continua.
Una de las habilidades impresionantes de ADO es su capacidad para manejar casi cualquier situación de CI / CD. Fuera de la caja, el servicio ofrece muchas tareas predefinidas, lo que le permite crear rápidamente cadenas CI / CD para la mayoría de los proyectos modernos con solo unos pocos clics.
Si sus necesidades no son parte del servicio básico, el Mercado generalmente le proporcionará muchas herramientas adecuadas diferentes. Si esto no funciona, puede dibujar un script de PowerShell que haga el trabajo que necesita.
El problema obvio del proyecto era que, a pesar de la amplia gama de características de servicio, el ensamblador cruzado y las imágenes de disco para Commodore 64 simplemente no existían. Por supuesto, podría crear una máquina virtual especial en Azure con las herramientas que necesitaba, o seguir la ruta de PowerShell, pero ¿sería interesante?
Tampoco me gustan las máquinas virtuales en la nube, y para este ejercicio quería usar agentes alojados, así que solo tenía una opción. Para demostrar para qué estaba destinado todo el ejercicio, decidí que sería mejor crear mi propia extensión para manejar todas estas tareas.
Extensión de ensamblador cruzado ACME
La primera extensión necesaria para mi cadena de CI fue compilar mi código de ensamblador en el código de máquina C64. Para hacer esto, necesitaba instalar el ensamblador cruzado en uno de los agentes de compilación alojados.
Assembler es un programa que convierte el lenguaje ensamblador legible por humanos en código de máquina real diseñado para un controlador binario específico. Típicamente, el código de máquina se genera para el procesador utilizado en la máquina en la que se ejecuta. El ensamblador cruzado da el siguiente paso en la conversión de código, permitiéndole generar código de máquina para otro procesador.
Como mencioné, para mi proyecto elegí ACME Cross-Assembler, porque se recomienda para el desarrollo de Commodore. También es compatible con una amplia gama de otros proyectos de 8 bits, como el Nintendo Entertainment System o la familia Atari que utilizan procesadores 65xx.
Me llevó la mayor parte del día, en base a la documentación y ejemplos proporcionados por Microsoft y otras fuentes, escribir, verificar y publicar en el Mercado una versión funcional de la extensión.
Cuando se inicia, la tarea descarga automáticamente la última versión de ACME Cross-Assembler y la inicia con opciones que le permiten crear el archivo final para la plataforma de destino. Una de las ventajas asociadas con la elección de ACME es que la mayoría de los parámetros para construir el programa están integrados en el código fuente, lo que minimiza la cantidad de entrada que debe definirse en la extensión.
¿Alguien tiene un disquete prestado?
El siguiente paso en la cadena es transferir el programa a un formato multimedia compatible con Commodore 64, es decir, colocarlo en un disquete. Los desarrolladores tampoco enfrentan ese problema en la vida cotidiana. Afortunadamente, existen aplicaciones separadas para esta tarea.
VICE es el emulador más popular para Commodore. No solo tiene muchos emuladores para cada uno de los diversos modelos de Commodore, sino también varias herramientas útiles, incluido el administrador de discos virtuales c1541. Las imágenes de disco creadas con él pueden usarse con el emulador, copiarse a medios físicos (5 "disquete de baja densidad) o descargarse a microSD y usarse con el emulador de unidad SD2IEC.
A diferencia de la tarea ACME, que toma todas las configuraciones del encabezado del archivo fuente, la utilidad de disco c1541 se basa en la CLI y el usuario tiene muchas opciones para administrar el disco. Para mi extensión, decidí centrarme solo en las propiedades necesarias para mi tarea, pero incluso entonces me enfrenté a una elección relacionada con lo completamente que necesitaba para hacerlo.
Commodore lanzó tres modelos de unidades diferentes, que difieren en la forma en que manejan los volúmenes de disco según el formato y el tipo de medio. El modelo básico, familiar para la mayoría de los usuarios, solo podría funcionar con unidades de un solo lado con una capacidad de 170 KB (sí, kilobytes. Pregúntele a sus padres). El modelo posterior, 1571, utilizado en el Commodore 128, podría funcionar con unidades de doble cara, cuyo volumen aumentó a 340 Kb. Decidí agregar flexibilidad a la extensión, por lo que agregué soporte para varios formatos de disco como una configuración, que se puede seleccionar en la interfaz a través del menú desplegable.
Como ya tenía un ejemplo de trabajo, la creación de esta extensión fue mucho más rápida. Aprendí algo nuevo que también me permitió mejorar el código para la extensión ACME.
Como en el caso del ensamblador cruzado, el software requerido se descarga del repositorio de proyectos de código abierto y se instala en el agente de compilación. La tarea crea una imagen de disco en el formato deseado y luego se copia el archivo de la tarea de compilación. El archivo resultante se mueve al directorio Build Artifacts, donde puede descargarlo.
¿Qué es lo que resulta? ¿Tanto trabajo, y como resultado necesitas descargar el archivo? Este debe ser material de capacitación de CI / CD. Si necesitamos demostrar nuestra posición, debemos implementar el programa en la máquina para que pueda usarse como demostración.
Floppinet deshabilitado
Ejecutar versiones de una computadora Commodore 64 real y una unidad 1541 es algo raro, sin mencionar que es grande y pesado. Además, no pueden mostrar imágenes en monitores modernos sin adaptadores especiales, y esto limita en gran medida la efectividad de la demostración.
La Commodore SX-64 (la primera computadora en color "portátil" que se fabricó en grandes lotes) tenía un monitor incorporado, pero era aproximadamente del tamaño de mi maleta de mano y pesaba unos 10 kg. ¿Imagina lo difícil que sería pasar por el servicio de seguridad del aeropuerto con semejante monstruo?
El
C64 Mini recientemente lanzado es lo suficientemente pequeño como para viajar, la capacidad de descargar programas desde USB y una salida HDMI. En algunos casos, esta sería una opción. Pero todavía no logra el objetivo deseado.
El verdadero problema no es la portabilidad de la plancha, sino la falta de automatización. La necesidad de transferir el programa de una computadora portátil a un automóvil utilizando una unidad flash no revela completamente las capacidades de ADO en la presentación.
Opción sin servidor
Como mencioné, VICE es el emulador más popular para Commodore. Fue portado a Windows, Linux, Mac OS X, MS-DOS y muchos otros sistemas operativos. Sin embargo, para el desarrollo en la nube, esta opción requeriría configurar la VM como host, y quería seguir adelante con una solución que no requiera un servidor.
Además de las versiones mencionadas, VICE tiene una opción para JavaScript que funciona bien en la mayoría de los navegadores. Aunque el desarrollo front-end no es mi elemento, pude crear una página receptiva decente.
Para organizar la cadena de lanzamiento, subo un archivo con una imagen de disco a un directorio en el mismo repositorio. Asociado esto con llamar a la aplicación Azure Function, que devuelve una lista de imágenes de disco disponibles. Al seleccionar uno de ellos en el menú desplegable, se carga automáticamente y se inicia en un emulador de JavaScript.
El sistema no solo funciona con mi programa, sino que logré crear una cadena para implementar y ejecutar el programa en Commodore 64 BASIC.
10 PRINT "HELLO WORLD"
20 GOTO 10Terminamos
DevOps para Commodore 64? ¡Es impensable!
El significado de este ejercicio no es solo la prueba de que cuando dicen sobre Azure DevOps que admite "cualquier idioma y cualquier plataforma", no solo significan todo lo relacionado con Microsoft (aunque la versión BASIC para Commodore se compró bajo licencia de Microsoft) Nos distrae de concentrarnos en los aspectos tecnológicos y hace que las personas vayan más allá del marco artificial que han designado para sí mismas.
Independientemente de las excusas, declaraciones como "esto no funcionará aquí" a menudo equivalen a declaraciones "siempre lo hicimos de esta manera, por qué cambiar algo". Ambas frases demuestran una falta de voluntad para crecer y desarrollarse, adaptarse a un panorama tecnológico en constante cambio y superar los desafíos que plantean estos cambios rápidos y agresivos.
DevOps no son herramientas. Las herramientas al final son solo un medio para un fin, independientemente de quién las publique.
Para que DevOps tenga éxito en la organización, es necesario cambiar la forma de pensar y desarrollar nuestra cultura corporativa. Necesitamos aceptar muchas ideas nuevas, repensar lo que creemos que sabemos y alejarnos de pensamientos como "esto no funcionará aquí", porque no lo hemos intentado antes.
Crear una cadena de CI / CD para una computadora de 30 años no tiene valor para el negocio, excepto para ilustrar claramente este punto de vista.