Hemos avanzado en el proceso de crear un pylance utilizando Azure DevOps, una herramienta fundamental para la integración y entrega continua de aplicaciones. Es esencial tener acceso a los agentes o máquinas virtuales de Azure DevOps, los cuales ejecutan los comandos automáticamente en nuestras aplicaciones. A continuación, te explicaré cómo hemos gestionado la creación y ejecución de un pylance para una aplicación Node con REAP.
¿Qué necesitamos para comenzar?
Acceso a Azure DevOps: Utiliza una cuenta con acceso adecuado a los agentes de Azure DevOps. Para esto, puede ser necesario llenar un formulario y esperar de dos a tres días hábiles para la aprobación.
Configuración de Node: Asegúrate de estar trabajando con una versión actualizada de Node, en nuestro caso usamos Node 16.15.
¿Cómo guardar y ejecutar el Pylance?
Antes de ejecutar, es fundamental guardar el archivo azurepylance.yml dentro del repositorio. Esto permite:
Ejecutar todos los comandos de integración continua de manera automatizada.
Monitorear el inicio de la ejecución y seguir el progreso de las tareas configuradas.
# Ejemplo de configuración en azurepylance.ymltrigger:branches:include:- master
pool:vmImage:'ubuntu-latest'steps:-task: NodeTool@0
inputs:versionSpec:'16.15'displayName:'Install Node.js'
¿Cómo agregar y ejecutar nuevos scripts?
Para aprender a ejecutar diferentes scripts, separamos npm install de npm run build. Aunque no es una práctica común, nos ayuda en este proceso educativo.
-script:| npm installdisplayName:'npm install'-script:| npm run builddisplayName:'npm run build'
¿Cómo preparar el paquete de publicación?
Copia de archivos: Creamos una tarea para copiar los archivos generados durante la compilación a una carpeta de staging.
Publicación: Finalmente, publicamos este archivo para que otras secciones de Azure DevOps puedan usarlo, especialmente para la sección de releases que usaremos más adelante.
Azure DevOps ofrece amplias funcionalidades, desde la ejecución de pruebas unitarias hasta el análisis de calidad del código mediante SonarQ. Aunque nuestro ejemplo es básico, estas herramientas pueden ser integradas para proyectos más avanzados.
Consejos para continuar el aprendizaje
Te animo a experimentar con diferentes configuraciones y opciones que Azure DevOps ofrece. La práctica y exploración te permitirán optimizar este tipo de procesos, hacerlos más robustos, e incluso automatizar tareas repetitivas eficientemente. Además, ¡No dudes en consultar la documentación de Azure DevOps para descubrir todo su potencial!
- script:| npm install
displayName:'npm install'- script:| npm run build
displayName:'npm run build'- task:CopyFiles@2inputs:Contents:'build/**'TargetFolder:'$(build.ArtifactStagingDirectory)'- task:ArchiveFiles@2inputs:rootFolderOrFile:'$(Build.ArtifactStagingDirectory)'includeRootFolder:truearchiveType: zip
archiveFile:'$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'replaceExistingArchive:true- task:PublishBuildArtifacts@1inputs:PathtoPublish:'$(Build.ArtifactStagingDirectory)'ArtifactName:'drop'
Cordial saludo
task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
#publishLocation: 'Container'
Es posible comentariar líneas en nuestro task utilizando #
Si el pipeline se ejecuta con cada nuevo commit en la rama asignada, para este caso master, cuando quiera hacer un pull request hacia esa rama y se apruebe haciendo un merge, ¿El pipeline se ejecutará una vez (por la acción de merge) o n veces según el número de commits en el merge?
Correcto, se puede ejecutar por un commit directo a master o por un merge hacia master
Influye que en cap. 14 y Cap 15 sea distinto el repo?
Este cambio fue por que utilizamos una cuenta diferente que tenia los permisos para poder ejecutar el pipeline. No influye en nada el nombre del proyecto, es el mismo repo.
El error como se soluciono... ???
dicen que hay que llenar un formulario, pero en la clase anterior no lo mostraron..
Solo hay que llenar el formulario, y espera de 2 a 3 días hábiles para que el equipo de Azure nos habilite el uso de las máquinas virtuales.
Hay un curso o algo mas enfocado a los PipeLines ? gracias!
Yo también quiero saber ello alguien sabe ?
# Node.jswithReact# Build a Node.js project that uses React.# Add steps that analyze code, save build artifacts, deploy, and more:# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:- master
pool:vmImage: ubuntu-latest
steps:- task:NodeTool@0inputs:versionSpec:'10.x'displayName: 'InstallNode.js- script:| npm install
displayName:'npm install'- script:| npm run build
displayName:'npm run build'- task:CopyFiles@2inputs:Contents:'build/**'TargetFolder:'$(Build.ArtifactStagingDirectory)'- task:ArchiveFiles@2inputs:rootFolderOrFile:'$(Build.ArtifactStagingDirectory)'includeRootFolder:truearchiveType: zip
archiveFile:'$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'replaceExistingArchive:true- task:PublishBuildArtifacts@1inputs:PathtoPublish:'$(Build.ArtifactStagingDirectory)'ArtifactName:'drop'
¿Qué podría suceder para que el archivo zip no se pueda crear? En el release me sale la advertencia ##[warning]No archives were found using specified file patterns
Es probable que quedara en otra carpeta también. recuerda que en la parte de releases tiene la opción de explorar las carpetas y entonces ahí puedes explorar las subcarpetas y ver donde quedo el .zip desde el pipeline.
Estimado Miguel, conoces de algún caso donde sea necesario acceder directamente a la máquina virtual que se crea el pipeline para hacer modificaciones manuales ?? ó el acceso a ese agente es restringido a las tareas del pipeline solamente ?
El agente esta restringido a la ejecución del pipeline, realmente no deberia como tal modificarse, la idea es que sea un ambiente aislado que solo sirva para puntualmente los pasos del pipeline.
Hola Carlos, yo si he ocupado hacer eso en algunos casos, cabe aclarar que sólo es posible en agenges autohosteados y creo que es muy común, por ejemplo si requieres actualizar la versión del framework que realiza la compilación, también puedes acceder con la intención de instalar herramientas perifericas que se ejecuten en el pepiline via shell como comprimir archivos. El ejemplo más significativo es si el agente realiza compilaciones de imágenes, cada versión nueva se va quedando en el registro de docker y aunque funciona por capas a la larga (unos 3 meses de trabajo continuo) el disco del agente se comienza a llenar y hay que entrar a depurarlo o dejar un script automatizado que lo haga, todo eso dentro del mismo agente de compilación.
Por que no se debe usar publishLocation:'Container ' ?
Minuito 12:40
Se pudo haber dejado igual por que ese es el valor por defecto, significa que el publish se va guardar dentro de la ejecución de ese pipeline:
Choose whether to store the artifact in Azure Pipelines (Container), or to copy it to a file share (FilePath) that must be accessible from the build agent. To learn more, see Artifacts in Azure Pipelines.
Default value: Container
Qué hace exactamente la parte de PublishBuildArtifacts? Entiendo que la publicación se hace recién en la parte de release
Mike, puedes abundar mas sobre como resolviste el error, dices que una cuenta configurada, pero en si que es lo que se configura, que solicitudes se levantan, que tenemos que considerar.. gracias, no me queda claro como se resuelve...
Es raro que el video este cortado, pero basicamente lo que tiene que hacerse es llenar el form y pedir acceso para poder ejecutar los pipelines, esto pasa por que mucha gente ha hecho mal uso de los pipelines para malos propositos
Buena tarde, hasta ahora me ha encantado el curso :D, sin embargo, tengo una preguntita..
¿Cómo sabes cuales son los inputs que debes rellenar? Por ejemplo, en el caso de la tarea CopyFiles version 2; colocaste Contents y target Folder.
Previamente ya tenia listo el código, la manera de poder saber las propiedades es revisar la documentación:
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops
Busca por copy files y vas a encontrar los diferentes parámetros que soporta y su funcionalidad.
La idea es que cuando tengas que hacer algo en particular busques en los Task que soporta Azure devops para utilizar el que te sirve para ese escenario.
A dia de hoy que ando haciendo el curso si se deja la version mas actual de node generara error el pipeline debido a la version del proyecto, me funciona dejando la version 16 en el archivo :D
Gracias. Lo hize tal cual y funciono. Al parecer es una incompatibilidad entre la version mas actual de Node.js y el OpenSSL del proyecto.
Si al ejecutar el Pipeline les sale el siguiente error:
En un pipeline como estos, supongo es posible lanzar procesos custom, pegarle a un endpoint para ejecutar una acción por ejemplo. Me gustaría poder recibir un webhook cuando se crea un PR y ejecutar algunos procesos custom con Node o Python cuando eso suceda.
¿Por que se debe realizar la tarea de comprimir y que sucede si no se realiza?
No es necesaria, se hizo a modo de demo. El valor que tiene hacerlo es poder. manipular los artefactos como un solo archivo y poder moverlos a otras partes de la aplicación que la necesiten.
Quise decir a otras partes de Azure DevOps que la necesiten o vayan a usarla
A mi no me queda claro por qué no funciona el pipeline sin el task pulbish, osea con los tasks anteriores ya estamos pasando el .zip a la misma ruta en la que se se quiere publicar el artifact, no?
El publish permite que otros pipelines y tareas dentro de Azure DevOps puedan acceder al artefacto generado