Intégration Continue pour PowerBuilder

1. Exécuter des tests unitaires localement

Les tests unitaires peuvent être exécutés manuellement, ou écrits et automatisés selon les pratiques de développement piloté par les tests.

Tous les tests unitaires doivent réussir dans l'environnement local du développeur avant que ses modifications soient intégrées dans la version principale. Cela évite que son travail en cours ne casse les copies des autres développeurs.

2. Valider les modifications et générer un build

Les développeurs soumettent leurs modifications au référentiel et fusionnent leur branche de code avec la version principale.

Un serveur de build compile le code périodiquement, voire après chaque commit, et transmet les résultats aux développeurs.

PowerBuilder 2025 et 2025 R2 renforcent l'intégration continue avec un nouveau compilateur haute performance (éditions CloudPro et Professional) et des processus d'automatisation simplifiés.

Les versions récentes de PowerBuilder offrent un ensemble de fonctionnalités qui simplifient ce processus :

Outil de compilation PBAutoBuild

PBAutoBuild est l'outil de build autonome en ligne de commande de PowerBuilder, disponible depuis PowerBuilder 2021. Il compile et déploie les projets en dehors de l'IDE, ce qui en fait le point d'entrée d'un workflow CI/CD. Il ne nécessite ni l'IDE PowerBuilder ni licence PowerBuilder sur la machine de build : seuls PowerBuilder Utilities et PowerBuilder Runtime sont requis (ainsi que PowerServer Toolkit pour les projets PowerServer).

PBAutoBuild peut compiler :

• des applications client/serveur
• des projets PowerClient
• des projets PowerServer

Dans PowerBuilder 2025, PowerBuilder Compiler (PBC) est intégré à PBAutoBuild250.exe : les scripts PBC existants continuent de fonctionner en ajoutant le paramètre /pbc. PBAutoBuild propose également une option "deploy only" (déploiement seul).

Si vous utilisez PowerBuilder 2019 ou 2017, consultez cet article pour savoir comment utiliser l'outil précédent "PowerBuilder Compiler".

Intégration avec les systèmes de contrôle de version

PowerBuilder s'intègre nativement aux systèmes de contrôle de version tels que GIT, SVN ou des systèmes externes compatibles avec l'API SCC. Cela simplifie le partage d'une version commune du code et sa récupération à des fins de CI/CD.

Remarque : l'API SCC et PBNative ne fonctionnent qu'avec le format workspace traditionnel ; le format Solution introduit dans PowerBuilder 2025 prend en charge Git et SVN.

Langage ORCAScript

Le langage ORCAScript est destiné à effectuer des opérations de contrôle de version et à construire des bibliothèques, des workspaces et des exécutables PowerBuilder sans intervention humaine.

La compilation ORCAScript ne s'applique qu'au format workspace : les solutions sont compilées avec PBAutoBuild.

3. Vérifier le code

La vérification du code s'appuie sur l'analyse statique pour identifier les vulnérabilités de sécurité, les bugs, les problèmes de performance et de qualité, en contrôlant le code source à l'aide de règles prédéfinies. Dans un workflow CI/CD, les résultats aident les équipes à évaluer la qualité du code et à déterminer si un build est prêt à être déployé.

À mesure que les assistants IA accélèrent le développement, garantir la qualité du code devient encore plus important. Chaque modification doit être vérifiée, que le code ait été écrit par un développeur ou généré par l'IA. La vérification automatisée fournit un contrôle cohérent et indépendant sur l'ensemble du code.

Mais la détection des défauts n'est que la première étape. Améliorer la qualité du code exige un processus continu : vérifier le code, analyser et prioriser les résultats, évaluer l'impact des corrections envisagées, corriger, puis vérifier à nouveau pour confirmer leur résolution.

Vérifier le code à chaque build

Dans un workflow CI/CD, la vérification doit s'exécuter automatiquement à chaque build, couvrir à la fois le code applicatif et le code de base de données, et produire des résultats qui aident à décider si le build peut être déployé.

Par exemple, Visual Expert permet de vérifier le code PowerBuilder et le code de base de données :

• Analyse du code source depuis GIT, SVN, Azure DevOps Server (anciennement TFS), des dossiers Windows, Oracle ou SQL Server. 
• Détection des vulnérabilités de sécurité, des bugs, des problèmes de qualité et de performance, ainsi que du code mort.
• Synthèse de chaque analyse dans un tableau de bord des défauts présentant les défauts actifs, nouveaux, critiques et résolus, ainsi que les évolutions depuis l'analyse précédente. Ces indicateurs aident les équipes à évaluer si le build répond à leurs critères de mise en production.
• Rapports détaillés de revue de code localisant chaque défaut au niveau de l'instruction.

Tableau de bord des défauts : indicateurs de qualité et tendances d'une analyse à l'autre

Gérer les défauts, de la détection à la résolution

À mesure qu'une application grandit, une seule vérification peut remonter des centaines de résultats. Sans processus structuré, ces résultats sont difficiles à prioriser, les responsabilités restent floues et l'avancement des corrections est difficile à mesurer. Les équipes ont donc besoin de pouvoir :

• Prioriser : identifier les défauts et les vulnérabilités à traiter en premier, en fonction de leur gravité
• Qualifier : marquer les faux positifs et les risques acceptés, afin que ces décisions soient conservées lors des analyses suivantes
• Assigner : répartir le travail de correction entre les membres de l'équipe
• Suivre : suivre chaque défaut jusqu'à sa résolution et s'assurer que les problèmes critiques sont clôturés avant la mise en production
• Mesurer : évaluer la qualité globale du code au fil des analyses pour vérifier qu'elle progresse

Visual Expert accompagne ce processus en conservant les défauts, les décisions, les statuts, les responsables et l'historique d'une analyse à l'autre.

Évaluer l'impact avant de corriger

Dans les applications PowerBuilder et de bases de données, un même objet, une même procédure ou une même table est souvent utilisé à de nombreux endroits. Le modifier sans savoir ce qui en dépend peut introduire de nouveaux défauts ailleurs.

Avant d'appliquer une correction, les équipes doivent savoir ce que la modification va affecter. Par exemple, l'analyse d'impact de Visual Expert montre quels objets, procédures et tables dépendent du code modifié, ce qui aide les équipes à définir le périmètre de la modification et les tests à réaliser ensuite.

Corriger avec l'assistance de l'IA

L'assistance de l'IA peut accélérer les corrections, à condition que chaque modification proposée soit relue par un développeur, puis vérifiée à nouveau.

Par exemple, avec Visual Expert AI, les développeurs peuvent utiliser Suggérer une solution sur un défaut issu des résultats de vérification. Visual Expert propose un code corrigé, accompagné de commentaires dans le code et d'une explication des modifications, pour aider les développeurs à examiner la correction proposée. Les développeurs gardent la main : ils examinent la proposition, l'adaptent si nécessaire, puis l'appliquent.

Lorsque le code est peu familier, Expliquer la logique peut également fournir un résumé de ce que fait une fonction ou une procédure.

Confirmer la résolution

Une correction n'est terminée qu'une fois vérifiée. Une nouvelle analyse confirme que le défaut n'est plus détecté, et son statut ainsi que son historique sont mis à jour. Répétée à chaque build, cette vérification continue permet de détecter rapidement les régressions, d'éviter l'accumulation de défauts non résolus et de maintenir la qualité et la sécurité du code dans la durée.

4. Tester le build - Continuous Testing

L'intégration continue vise à automatiser les tâches pour vérifier et générer des builds déployables aussi souvent que possible. 

Les tests sont une étape essentielle de ce processus, et leur automatisation est indispensable pour atteindre cet objectif : chaque build est testé en profondeur et les indicateurs générés automatiquement permettent d'évaluer s'il est déployable.

L'automatisation des tests est-elle productive ?

Les générations d'outils précédentes avaient la réputation de demander trop d'efforts pour créer et maintenir les tests, ce qui allait à l'encontre de l'objectif de gain de productivité.

Elles reposaient souvent sur 2 stratégies :

• Le développement de scripts pour spécifier les tests - coûteux à développer.
• L'enregistrement d'actions de test à l'écran - facile à créer, mais peu résistant aux changements d'interface graphique et trop coûteux à maintenir.

Les outils modernes offrent une approche différente, basée sur la reconnaissance d'objets :

• Analyse du code pour identifier les objets
• Définition des actions de test en sélectionnant un objet et un type d'action (cliquer sur un bouton, saisir une valeur dans un champ…). Beaucoup plus simple que l'écriture de scripts : des compétences en programmation ne sont plus nécessaires.
• Les objets étant stables, les tests résistent très bien aux modifications de l'interface utilisateur. Les coûts de maintenance sont bien inférieurs à ceux des outils d'enregistrement.

En savoir plus

• Tests basés sur les objets vs tests basés sur l'enregistrement
• Tests automatisés et gestion du cycle de vie des applications

Tests automatisés vs tests manuels

Comparons les deux stratégies à l'aide d'indicateurs clés :

	Manuel	Auto
Précision	❌	✓	Les tests manuels sont moins précis en raison des erreurs humaines possibles. Les tests automatisés sont cohérents et fiables.
Productivité	❌	✓	L'exécution de nombreux tests manuels prend du temps et coûte cher. Les tests automatisés sont plus rapides. Aucun coût supplémentaire pour les répéter autant de fois que nécessaire.
Démarrage	✓	❌	Vous pouvez commencer à exécuter des tests manuels immédiatement. Les tests automatisés nécessitent un travail préalable pour définir les tests et les actions.
Flexibilité	✓	❌	Le test manuel est plus flexible : il permet de tester de manière aléatoire ou d'improviser à la volée des tests approfondis sur une zone très précise. Ce n'est pas le cas du test automatisé.

Les tests automatisés apportent évidemment des avantages majeurs, mais ne peuvent pas remplacer entièrement les tests manuels.

La meilleure stratégie consiste à combiner judicieusement les 2 approches en fonction :

• de la nature et de la stabilité des tests 
• du temps disponible pour créer des tests automatisés 
• de l'existence d'un workflow d'intégration continue
• ...

Pour aller plus loin :

• Structurer les tests manuels en complément des tests automatisés
• Tests continus dans un workflow CI/CD

Automatisation des tests pour PowerBuilder

Vous pouvez utiliser AscentialTest pour automatiser les tests des applications PowerBuilder et PowerServer

• Intégration avec SVN pour le contrôle de version.
• Intégration avec JIRA pour le suivi des défauts.
• Exécution des tests en ligne de commande depuis des serveurs d'automatisation tels qu'Azure DevOps (y compris Azure DevOps Server, anciennement TFS) et Jenkins.
• Plugin AscentialTest pour Jenkins et extension de tâche de pipeline pour Azure DevOps.

5. Localiser votre application

Les outils modernes permettent d'automatiser diverses tâches dans un workflow CI/CD. La prise en charge multilingue en fait désormais partie.

Si votre application est déployée dans plusieurs pays, vous la traduisez probablement pour mieux servir vos utilisateurs. Une fois en production, vous devez systématiquement mettre à jour les traductions afin de maintenir une expérience utilisateur cohérente.