What is Continuous Integration (CI)?

The concept of continuous integration (CI) is the practice of merging several times a day all developers' working copies to a centralized version, hosted in a shared repository.

Automated deployments lead to continuous delivery (CD), a frequent extension of continuous integration.
In order to deploy reliable releases, continuous delivery involves verifying build compliance with quality, stability and security requirements through automated testing and static code analysis to detect bugs, quality issues and vulnerabilities (SAST).

Each code update is therefore automatically checked and, if accepted, can be deployed in production.

Ultimately, a CI/CD workflow will increase the agility and productivity of your development team as well as code quality and security .

Why Implement CI/CD for PowerBuilder Apps?

Before submitting their code to the repository, developers must first update it to reflect the changes made since they took their copy. 

  1. If they do it frequently, the repository will contain less changes and they will have less work to do before submitting their own modifications.
  2. The risk of multiple integration conflicts when their code branch is merged back is reduced.
  3. By testing the code frequently developers will discover bugs sooner. It is less expensive to fix them because developers still have in mind the code they just wrote.
  4. CI reduces the risk of other teammates building on code containing bugs, which would generate additional bugs and fixing costs.

Continuous Integration / Continuous Delivery Workflow

A typical CI/CD workflow would be composed of the following steps:

Continuous Integration Workflow

Related article

Implement CI/CD for PowerBuilder with your Automation Server
Use Jenkins, Gitlab, Azure DevOps with 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.

Tools & Resources

2. Commit changes and generate a build

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

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

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

  • PB 2021 introduces PBAutoBuild, to build your applications and initiate a CI/CD workflow.
    • Building your client/server application with commands
    • Building your PowerClient project with commands
    • Building your PowerServer project with commands
    • If you are using PowerBuilder 2019 or 2017, refer to this article to learn how to use the previous tool "PowerBuilder Compiler".
  • PowerBuilder also integrates natively with source controls like GIT or SVN. This simplifies sharing a common version of the code and fetching it for CI/CD purposes.
  • The ORCAScript language is meant to perform source control operations and build PowerBuilder libraries, workspaces and executables without human intervention.

Tools & Resources

3. Inspect the Code

Code inspection tools running a static analysis to identify defects.

Each block of code is checked against a set of rules to find security vulnerabilities, bugs and maintainability issues. A report is automatically generated to count and classify defects by severity, and evaluate whether a build is acceptable for deployment or not.

You can use Visual Expert to inspect your PowerBuilder and Database code:

   

Locating issues at instruction level


Code review dashboard with high-level indicators

Tools & Resources

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.

Why Automate Testing?

Obviously, every team tests its products.
Yet all delivery includes defects.

Testers strive to catch them: some always remain, while others reappear, no matter how thorough the manual testing.

A test automation tool is a very efficient way to supplement your manual testing, for improving the efficiency and coverage of your testing operations.

Read more: steps to create automated tests

Test Automations Tasks

Is test automation productive?

Previous generations of tools had the reputation of requiring too much efforts 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.

This example of automated test will start the application, select an authentication method, enter credentials, and click on the login button.

Read More

Automated Vs. Manual testing

Let's compare both strategies with critical KPIs:

  Manual Auto  
Accuracy Manual Testing is less accurate because of the possible human errors.
Automated testing is consistent and reliable.
Productivity Executing lots of 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 deepers 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:

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 through third-party tools like TFS, Azure, and Jenkins.
  • AscentialTest plug-in for Jenkins.

Tools & Resources

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.

 

Tools & Resources

Enable for PowerBuilder separates translations from code, and includes specific features to integrate in a CI/CD pipeline:

  • Extracting new strings and importing them into the multilingual database
  • Exporting phrases and translations to a file (Json, XML, Excel)
  • Importing translations from a file (Json, XML, Excel)

You can add a multilingual task to your workflow, for example:

  1. Extracting and loading new phrases into the multilingual database.
  2. You can optionally pre-translate them if the translation memory has translations.
  3. Importing translations into the multilingual database Generating a NEW BUILD with multilingual phrases updated

Note: phrases are usually translated by professional translators. They will send back the translations, for automatic import into the multilingual database. This second process is independent of the build process.