Microsoft ha publicado en versión preliminar pública logicapp, una extensión de Azure CLI para desarrollar y probar proyectos de Azure Logic Apps Standard desde la línea de comandos. Permite crear proyectos, editar archivos de flujo, iniciar un runtime local y revisar ejecuciones. Así, esas tareas ya no dependen exclusivamente de Visual Studio Code, aunque el diseñador visual sigue siendo una herramienta distinta y la extensión no elimina la necesidad de Azure cuando se trabaja con recursos desplegados.
De administrar aplicaciones desplegadas a trabajar con proyectos locales
Hasta ahora, la CLI de Azure permitía gestionar aplicaciones de Logic Apps Standard ya desplegadas. La extensión conserva esos comandos de administración en la nube y añade una superficie local: según la información publicada por InfoQ sobre el anuncio de la extensión, incorpora 19 grupos con 64 comandos, además de los 13 comandos existentes para la gestión en la nube.
La extensión se instala automáticamente cuando se ejecuta por primera vez un comando de desarrollo az logicapp, siempre que Azure CLI sea la versión 2.67.0 o posterior. Esto añade una dependencia que conviene tener presente en los entornos de desarrollo y automatización: la versión de la CLI y la de la extensión no son lo mismo, y, según InfoQ, las extensiones de Azure CLI no se actualizan junto con la CLI.
En el trabajo con archivos, project create crea un proyecto local o adopta uno existente. Los comandos workflow create, set, export y validate actúan sobre archivos individuales workflow.json. La validación funciona sin conexión de forma predeterminada, lo que permite comprobar aspectos del flujo sin que esa operación tenga que consultar Azure.
Runtime local, conectores y seguimiento de ejecuciones
Los comandos runtime start, stop y show controlan un host local que utiliza el puerto 7071. Si el proyecto está configurado para usar almacenamiento de desarrollo, al iniciar el runtime también se pone en marcha el emulador de almacenamiento Azurite. De este modo, el proyecto puede ejecutarse en un entorno local con las dependencias previstas para ese modo de desarrollo, aunque eso no demuestra por sí solo que el flujo vaya a comportarse igual con todos los servicios reales.
La extensión también permite inspeccionar conectores integrados y gestionados, y configurar conexiones para un proyecto o una aplicación desplegada. Esta distinción importa: que la edición del flujo sea local no implica que todas sus conexiones o efectos sean locales. La información sobre la herramienta advierte de que algunos comandos modifican conexiones desplegadas y de que ciertos recorridos de uso emplean recursos reales de Azure y Microsoft 365. Antes de ejecutar comandos contra una aplicación existente, hay que identificar el destino y confirmar qué recursos cambiarán.
Para observar ejecuciones, los grupos run y trigger history incluyen operaciones para iniciar, esperar, cancelar y volver a enviar ejecuciones. También pueden descargar las entradas y salidas registradas de una acción. Esto aporta información útil para diagnosticar un flujo, pero los datos de una ejecución pueden contener información sensible; su acceso y almacenamiento deben tratarse con las mismas precauciones que los registros de la aplicación.
Otro comando, deployment package, genera un paquete de despliegue que la documentación describe como determinista. La extensión ofrece además contextos con nombre para guardar un destino y reutilizarlo en comandos posteriores, en lugar de repetir sus datos en cada llamada. Estas funciones pueden ordenar tareas repetidas, pero no sustituyen la revisión del destino antes de operar sobre recursos desplegados.
Comprobaciones y pruebas con límites explícitos
El comando runtime doctor tiene un alcance deliberadamente acotado: solo lee archivos del proyecto, versiones de herramientas, indicios almacenados en caché sobre componentes y puertos de loopback. Según la descripción recogida por InfoQ, no instala ni descarga elementos, no inicia ni detiene servicios, no repara configuraciones, no descifra ajustes ni contacta con el almacenamiento en la nube. Devuelve el código de salida 1 si falla una comprobación obligatoria y 2 si una comprobación requerida queda como desconocida.
El flujo de pruebas se divide también en pasos diferenciados. test create crea el esqueleto de un proyecto de pruebas con el SDK nativo, pero no restaura paquetes ni ejecuta pruebas. test plan genera un informe previo sin ejecutar código. Solo test run compila y ejecuta las pruebas, con un límite de tiempo. La separación permite revisar la preparación antes de lanzar la ejecución, pero no convierte el código de prueba en código aislado: la información sobre la extensión señala que las pruebas del SDK nativo se consideran confiables y no se ejecutan en un entorno aislado.
La validación del flujo tampoco acredita que las conexiones tengan autorización suficiente ni que la lógica cumpla los requisitos del negocio. En una integración, por ejemplo, validar la estructura de un archivo no confirma que una cuenta pueda acceder al sistema de destino ni que los datos transformados sean los esperados. Esas comprobaciones requieren pruebas adecuadas para las conexiones y el comportamiento que se quiere verificar.
Una opción para automatizar el ciclo, no un reemplazo del diseñador
La interfaz de comandos encaja en equipos que quieran incorporar la creación, validación y ejecución de flujos a scripts o procesos de integración continua. También ofrece operaciones estructuradas para que un asistente de programación pueda editar un flujo y pedir después una validación o una ejecución reproducible. Ese uso es una posibilidad que se desprende de las funciones de la CLI, no una garantía de que el proceso sea completamente autónomo o seguro.
InfoQ señala que el diseñador continúa en Visual Studio Code: la extensión edita directamente workflow.json y no puede cambiar el estado de una aplicación local que ya está en ejecución. También recoge límites sobre las pruebas en Linux: sus resultados no demuestran por sí mismos la ejecución nativa del SDK ni el comportamiento frente a Azure real. Para comparar resultados entre entornos, resulta útil registrar las versiones de Azure CLI, la extensión, el runtime y el proyecto.
La versión preliminar amplía el trabajo posible desde terminal, pero separa con claridad edición, validación, ejecución y efectos sobre recursos remotos. Esa distinción es especialmente relevante al trasladar los comandos a automatizaciones: una comprobación local puede ayudar a detectar errores antes del despliegue, pero no reemplaza las pruebas de integración ni la revisión de las conexiones que alcanzan servicios reales.
