Integración Continua para PowerBuilder

1. Ejecutar pruebas unitarias localmente

Las pruebas unitarias pueden ejecutarse manualmente, o escribirse y automatizarse según las prácticas de desarrollo guiado por pruebas.

Todas las pruebas unitarias deben superarse en el entorno local del desarrollador antes de incorporar sus cambios a la versión principal. Así se evita que su trabajo en curso rompa las copias de otros desarrolladores.

2. Confirmar cambios y generar una compilación

Los desarrolladores envían sus cambios al repositorio y fusionan su rama de código con la versión principal.

Un servidor de compilación compila el código periódicamente, o incluso después de cada commit, e informa de los resultados a los desarrolladores.

PowerBuilder 2025 y 2025 R2 mejoran la integración continua con un nuevo compilador de alto rendimiento (ediciones CloudPro y Professional) y procesos de automatización simplificados.

Las versiones recientes de PowerBuilder ofrecen una serie de funcionalidades que simplifican este proceso:

Herramienta de compilación PBAutoBuild

PBAutoBuild es la herramienta de compilación independiente por línea de comandos de PowerBuilder, disponible desde PowerBuilder 2021. Compila y despliega proyectos fuera del IDE, lo que la convierte en el punto de entrada de un flujo de trabajo CI/CD. No requiere el IDE de PowerBuilder ni una licencia de PowerBuilder en la máquina de compilación: solo PowerBuilder Utilities y PowerBuilder Runtime (además de PowerServer Toolkit para los proyectos PowerServer).

PBAutoBuild puede compilar:

• Aplicaciones cliente/servidor
• Proyectos PowerClient
• Proyectos PowerServer

En PowerBuilder 2025, PowerBuilder Compiler (PBC) está integrado en PBAutoBuild250.exe: los scripts PBC existentes siguen funcionando añadiendo el parámetro /pbc. PBAutoBuild también incorpora una opción "deploy only" (solo despliegue).

Si usa PowerBuilder 2019 o 2017, consulte este artículo para aprender a usar la herramienta anterior "PowerBuilder Compiler".

Integración con sistemas de control de versiones

PowerBuilder también se integra de forma nativa con sistemas de control de versiones como GIT, SVN o sistemas externos compatibles con SCC. Esto simplifica compartir una versión común del código y obtenerla para fines de CI/CD.

Nota: la API SCC y PBNative solo funcionan con el formato workspace tradicional; el formato Solution introducido en PowerBuilder 2025 es compatible con Git y SVN.

Lenguaje ORCAScript

El lenguaje ORCAScript está destinado a realizar operaciones de control de versiones y a compilar bibliotecas, workspaces y ejecutables de PowerBuilder sin intervención humana.

La compilación con ORCAScript solo se aplica al formato workspace: las soluciones se compilan con PBAutoBuild.

3. Verificar el código

La verificación del código utiliza el análisis estático para identificar vulnerabilidades de seguridad, errores, problemas de rendimiento y de calidad, comprobando el código fuente con un conjunto de reglas predefinidas. En un flujo de trabajo CI/CD, los resultados ayudan a los equipos a evaluar la calidad del código y a determinar si una compilación está lista para su despliegue.

A medida que los asistentes de IA aceleran el desarrollo, garantizar la calidad del código es aún más importante. Cada cambio debe verificarse, tanto si el código lo ha escrito un desarrollador como si lo ha generado la IA. La verificación automatizada proporciona un control coherente e independiente sobre todo el código.

Pero detectar defectos es solo el primer paso. Mejorar la calidad del código requiere un proceso continuo: verificar el código, revisar y priorizar los resultados, evaluar el impacto de las correcciones propuestas, corregir y volver a verificar para confirmar su resolución.

Verificar el código en cada compilación

En un flujo de trabajo CI/CD, la verificación debe ejecutarse automáticamente en cada compilación, abarcar tanto el código de la aplicación como el de la base de datos y producir resultados que ayuden a decidir si la compilación puede desplegarse.

Por ejemplo, Visual Expert permite verificar el código PowerBuilder y de base de datos:

• Analiza el código fuente desde GIT, SVN, Azure DevOps Server (antes TFS), carpetas de Windows, Oracle o SQL Server. 
• Detecta vulnerabilidades de seguridad, errores, problemas de calidad y de rendimiento, así como código muerto.
• Resume cada análisis en un panel de defectos que muestra los defectos activos, nuevos, críticos y resueltos, junto con los cambios desde el análisis anterior. Estos indicadores ayudan a los equipos a evaluar si la compilación cumple sus criterios de puesta en producción.
• Proporciona informes detallados de revisión de código que localizan cada defecto a nivel de instrucción.

Panel de defectos: indicadores de calidad y tendencias entre análisis

Gestionar los defectos desde la detección hasta la resolución

A medida que una aplicación crece, una sola verificación puede notificar cientos de resultados. Sin un proceso estructurado, estos resultados son difíciles de priorizar, la responsabilidad no está clara y el avance de las correcciones es difícil de medir. Por eso, los equipos necesitan poder:

• Priorizar: identificar qué defectos y vulnerabilidades abordar primero, según su gravedad
• Calificar: marcar los falsos positivos y los riesgos aceptados para que estas decisiones se conserven en los análisis posteriores
• Asignar: distribuir el trabajo de corrección entre los miembros del equipo
• Hacer seguimiento: seguir cada defecto hasta su resolución y confirmar que los problemas críticos se cierran antes de la puesta en producción
• Supervisar: medir la calidad global del código a lo largo de los análisis sucesivos para comprobar si mejora

Visual Expert respalda este proceso conservando los defectos, las decisiones, el estado, los responsables y el historial a lo largo de los análisis sucesivos.

Evaluar el impacto antes de corregir

En las aplicaciones PowerBuilder y de base de datos, un mismo objeto, procedimiento o tabla suele utilizarse en muchos lugares. Modificarlo sin saber qué depende de él puede introducir nuevos defectos en otras partes.

Antes de aplicar una corrección, los equipos necesitan saber a qué afectará el cambio. Por ejemplo, el análisis de impacto de Visual Expert muestra qué objetos, procedimientos y tablas dependen del código que se modifica, lo que ayuda a los equipos a definir el alcance del cambio y las pruebas necesarias posteriormente.

Corregir con asistencia de IA

La asistencia de IA puede acelerar las correcciones, siempre que un desarrollador revise cada cambio propuesto y que este se vuelva a verificar.

Por ejemplo, con Visual Expert AI, los desarrolladores pueden usar Sugerir una solución sobre un defecto de los resultados de la verificación. Visual Expert propone código corregido, junto con comentarios en línea y una explicación de los cambios para ayudar a los desarrolladores a revisar la corrección propuesta. Los desarrolladores mantienen el control: revisan la propuesta, la adaptan si es necesario y la aplican.

Cuando el código no les resulta familiar, Explicar la lógica también puede proporcionar un resumen de lo que hace una función o un procedimiento.

Confirmar la resolución

Una corrección solo está completa cuando se ha verificado. Un nuevo análisis confirma que el defecto ya no se detecta, y se actualizan su estado y su historial. Repetida en cada compilación, esta verificación continua ayuda a detectar regresiones a tiempo, evita que se acumulen defectos sin resolver y mantiene la calidad y la seguridad del código a lo largo del tiempo.

4. Probar la compilación - Pruebas continuas

La integración continua tiene como objetivo automatizar tareas para verificar y generar compilaciones desplegables con la mayor frecuencia posible. 

Las pruebas son un paso esencial de este proceso, y su automatización es necesaria para lograr este objetivo: cada compilación se prueba exhaustivamente y los indicadores generados automáticamente ayudan a evaluar si es desplegable.

¿Es productiva la automatización de pruebas?

Las generaciones anteriores de herramientas tenían fama de requerir demasiado esfuerzo para crear y mantener las pruebas, lo que anulaba el objetivo de ganar productividad.

A menudo se basaban en 2 estrategias:

• Desarrollar scripts para especificar las pruebas: costoso de desarrollar.
• Grabar acciones de prueba en pantalla: fácil de crear, pero poco resistente a los cambios de la interfaz gráfica y demasiado costoso de mantener.

Las herramientas modernas ofrecen un enfoque diferente, basado en el reconocimiento de objetos:

• Analizar el código para identificar los objetos
• Definir las acciones de prueba seleccionando un objeto y un tipo de acción (hacer clic en un botón, introducir un valor en un campo…). Mucho más sencillo que escribir scripts: ya no se necesitan conocimientos de programación.
• Como los objetos son estables, las pruebas resisten muy bien los cambios de la interfaz. Los costos de mantenimiento son mucho menores que con las herramientas de grabación.

Más información

• Pruebas basadas en objetos vs. pruebas basadas en grabación
• Pruebas automatizadas y gestión del ciclo de vida de las aplicaciones

Pruebas automatizadas vs. manuales

Comparemos ambas estrategias con KPI clave:

	Manual	Auto
Precisión	❌	✓	Las pruebas manuales son menos precisas debido a posibles errores humanos. Las pruebas automatizadas son coherentes y fiables.
Productividad	❌	✓	Ejecutar muchas pruebas manuales lleva tiempo y es costoso. Las pruebas automatizadas son más rápidas. Sin costos adicionales para repetirlas tantas veces como sea necesario.
Inicio	✓	❌	Puede empezar a ejecutar pruebas manuales de inmediato. Las pruebas automatizadas requieren un tiempo previo para definir las pruebas y las acciones.
Flexibilidad	✓	❌	Las pruebas manuales son más flexibles: permiten probar de forma aleatoria o improvisar sobre la marcha pruebas más profundas en un área muy concreta. Las pruebas automatizadas no lo permiten.

Las pruebas automatizadas aportan evidentemente grandes beneficios, pero no pueden sustituir por completo a las pruebas manuales.

La mejor estrategia consiste en combinar con criterio los 2 enfoques en función de:

• la naturaleza y la estabilidad de las pruebas 
• el tiempo disponible para crear pruebas automatizadas 
• la existencia de un flujo de trabajo de integración continua
• ...

Para ir más lejos:

• Estructurar las pruebas manuales junto con las pruebas automatizadas
• Pruebas continuas en un flujo de trabajo CI/CD

Pruebas automatizadas para PowerBuilder

Puede usar AscentialTest para automatizar las pruebas de aplicaciones PowerBuilder y PowerServer

• Integración con SVN para el control de versiones.
• Integración con JIRA para el seguimiento de defectos.
• Línea de comandos para ejecutar pruebas desde servidores de automatización como Azure DevOps (incluido Azure DevOps Server, antes TFS) y Jenkins.
• Plugin de AscentialTest para Jenkins y extensión de tarea de pipeline para Azure DevOps.

5. Localizar su aplicación

Las herramientas modernas permiten automatizar diversas tareas en un flujo de trabajo CI/CD. La compatibilidad multilingüe es ahora una de ellas.

Si su aplicación se despliega en varios países, probablemente la traduzca para atender mejor a sus usuarios. Y una vez en producción, debe actualizar sistemáticamente las traducciones para mantener una experiencia de usuario coherente.