Continuous Integration for PowerBuilder

1. Run unit tests locally

Unit tests can be run manually, or written and automated according to test-driven development practices.

All unit tests should pass in the developer's local environment before incorporating his changes into the main release. This prevents his work in progress from breaking other developer's copies.

2. Commit changes and generate a build

Developers submit their changes to the repository and merge their branch of code back into the main version.

A build server compiles the code periodically or even after every commit and reports the results to the developers.

PowerBuilder 2025 and 2025 R2 enhance continuous integration with a new high-performance compiler (CloudPro and Professional editions) and simplified automation processes.

Recent versions of PowerBuilder offer a range of features simplifying this process:

PBAutoBuild Compilation Tool

PBAutoBuild is PowerBuilder's standalone command-line build tool, available since PowerBuilder 2021. It compiles and deploys projects outside the IDE, which makes it the entry point of a CI/CD workflow. It requires neither the PowerBuilder IDE nor a PowerBuilder license on the build machine, only PowerBuilder Utilities and PowerBuilder Runtime (plus PowerServer Toolkit for PowerServer projects).

PBAutoBuild can build:

• Client/Server applications
• PowerClient projects
• PowerServer projects

In PowerBuilder 2025, the PowerBuilder Compiler (PBC) is integrated into PBAutoBuild250.exe: existing PBC scripts keep working by adding the /pbc parameter. PBAutoBuild also adds a "deploy only" option.

If you are using PowerBuilder 2019 or 2017, refer to this article to learn how to use the previous tool "PowerBuilder Compiler".

Source Control Systems Integration

PowerBuilder also integrates natively with source controls like GIT, SVN or external SCC-compliant source control systems. This simplifies sharing a common version of the code and fetching it for CI/CD purposes.

Note: The SCC API and PBNative work only with the traditional workspace format; the solution format introduced in PowerBuilder 2025 supports Git and SVN.

ORCAScript Language

The ORCAScript language is meant to perform source control operations and build PowerBuilder libraries, workspaces and executables without human intervention.

ORCAScript compilation applies to the workspace format only: solutions are built with PBAutoBuild.

3. Verify the Code

Code verification uses static analysis to identify security vulnerabilities, bugs, performance problems, and quality issues by checking source code against predefined rules. In a CI/CD workflow, the results help teams assess code quality and determine whether a build is ready for deployment.

As AI assistants accelerate code development, ensuring code quality becomes even more important. Every change needs to be verified, whether the code was written by a developer or generated by AI. Automated verification provides a consistent, independent check across the entire codebase.

But detecting defects is only the first step. Improving code quality requires a continuous process: verify the code, review and prioritize findings, assess the impact of proposed fixes, remediate, and verify again to confirm their resolution.

Verify the code on every build

In a CI/CD workflow, verification must run automatically on each build, cover both application and database code, and produce results that help decide whether the build can be deployed.

For example, Visual Expert can be used to verify PowerBuilder and database code:

• Analyzing source code from GIT, SVN, Azure DevOps Server (formerly TFS), Windows folders, Oracle or SQL Server. 
• Detecting security vulnerabilities, bugs, code quality and performance issues, and dead code.
• Summarizing each analysis in a defect dashboard showing active, new, critical, and resolved defects, together with changes since the previous analysis. These indicators help teams assess whether the build meets their release criteria.
• Providing detailed code review reports that locate each defect at the instruction level.

Defect dashboard: quality indicators and trends across analyses

Manage defects from detection to resolution

As an application grows, a single verification can report hundreds of findings. Without a structured process, these findings are difficult to prioritize, ownership remains unclear, and progress on remediation is hard to measure. Teams therefore need a way to:

• Prioritize: Identify which defects and vulnerabilities to address first, based on their severity
• Qualify: Mark false positives and accepted risks so these decisions are preserved across subsequent analyses
• Assign: Distribute remediation work among team members
• Track: Follow each defect until it is resolved, and confirm that critical issues are closed before release
• Monitor: Measure overall code quality across successive analyses to see whether it is improving

Visual Expert supports this process by preserving defects, decisions, status, ownership, and history across successive analyses.

Assess impact before fixing

In PowerBuilder and database applications, a single object, procedure or table is often used in many places. Changing it without knowing what depends on it can introduce new defects elsewhere.

Before applying a fix, teams need to see what the change will affect. For example, Visual Expert impact analysis shows which objects, procedures and tables depend on the code being modified, helping teams define the scope of the change and the tests required afterward.

Remediate with AI assistance

AI assistance can speed up remediation, provided every proposed change is reviewed by a developer and verified again.

For example, with Visual Expert AI, developers can use Suggest a Solution on a defect from the verification results. Visual Expert proposes corrected code, together with inline comments and an explanation of the changes to help developers review the proposed fix. Developers stay in control: they review the proposal, adapt it if needed, and apply it.

When the code is unfamiliar, Explain the Logic can also provide a summary of what a function or procedure does.

Confirm the resolution

A fix is only complete once it has been verified. A new analysis confirms that the defect is no longer detected, and its status and history are updated. Repeated on every build, this continuous verification helps detect regressions early, prevents unresolved defects from accumulating, and maintains code quality and security over time.

4. Test the build - Continuous Testing

Continuous integration aims at automating tasks to verify and generate deployable builds as often as possible. 

Testing is an essential step in this process, and test automation is necessary to achieve this goal: each build will be thoroughly tested and indicators generated automatically will help assess if the build is deployable.

Is test automation productive?

Previous generations of tools had the reputation of requiring too much effort to create and maintain tests, which defeated the purpose of gaining productivity.

They were often based on 2 strategies:

• Developing scripts to specify tests - expensive to develop.
• Recording test actions on screen - easy to create, but not resistant to GUI changes and too expensive to maintain.

Modern tools offer a different approach, based on object recognition:

• Scanning the code to identify objects
• Defining test actions by selecting an object and a type of action (click a button, enter a value in a field…). Much simpler than writing scripts, coding skills are no longer required.
• Because objects are stable, tests are very resistant to UI change. Maintenance costs are much lower than recording tools.

Read More

• Object-based testing vs. Recording-based testing
• Automated Testing & Application Lifecycle Management

Automated Vs. Manual testing

Let's compare both strategies with critical KPIs:

	Manual	Auto
Accuracy	❌	✓	Manual Testing is less accurate because of possible human errors. Automated testing is consistent and reliable.
Productivity	❌	✓	Running many manual tests is time-consuming and expensive. Automated tests are faster. No additional costs to repeat as many times as needed.
Startup	✓	❌	You can start executing manual tests instantly. Automated testing requires preliminary time to predefine tests and actions.
Flexibility	✓	❌	Manual testing is more flexible: it allows testing randomly or improvising deeper tests on the fly in a very specific area. Automation Testing does not.

Automated Testing obviously brings major benefits but cannot fully substitute for manual testing.

The best strategy consists in wisely combining the 2 approaches depending on:

• the nature and stability of the tests 
• the time available for the creation of automated tests 
• the existence of a Continuous Integration Workflow
• ...

To go further:

• Structuring manual testing in conjunction with Automated testing
• Continuous testing in a CI/CD workflow

Automated testing for PowerBuilder

You can use AscentialTest to automate the test of PowerBuilder and PowerServer applications

• Integration with SVN through version control.
• Integration with JIRA through defect tracking.
• Command line for running tests from automation servers such as Azure DevOps (including Azure DevOps Server, formerly TFS) and Jenkins.
• AscentialTest plug-in for Jenkins and pipeline task extension for Azure DevOps.

5. Localize your Application

Modern tools make it possible to automate various tasks in a CI/CD workflow. Multilingual support is now one of them.

If your application is deployed in several countries, you probably translate it to better serve users. And once in production, you have to systematically update translations, to maintain a consistent user experience.