Tech Articles

Continuous Integration with PowerBuilder 2017, Bonobo Git and Jenkins

Print
Details
Category: PowerBuilder
Hits: 5371

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive
 
Note:  While the techniques described here still work, custom Jenkins plugins are now available which are easier to use.  They are described in this article.

 

In a previous blog post I examined how we could use the Git MSSCCI provider from PB Software in order to use GitHub as a source code provider for PowerBuilder.

In this blog post we're going to take that to the next step, in that we're going to create a build machine separate from our PowerBuilder development machine and then set it up to perform continuous integration.  The term "continuous integration" has a somewhat ambiguous definition, but generally it means that:

Ideally, automated testing routines would be run on each build to ensure that feedback on any functionality that was broken by the latest code changes are returned to the developers as soon as possible.  Automated testing is outside the scope of this particular article

One of the new features added in PowerBuilder 2017 is a license free stand alone compiler and we're going to use that for this article.   If you are using a older version of PowerBuilder you could use the same approach using the command line argument feature of the PowerBuilder IDE, but it would require installing the full PowerBuilder IDE (including a license) on the build machine.  Alternatively, regardless of which version of PowerBuilder you're using you could use PowerGen in scripted mode.

Prerequisites

Install Bonobo Git Server

Bonobo is a ASP.Net application, hence the need for the machine we're installing it on to have the .Net Framework installed and IIS configured for ASP.Net.  Installation is fairly straightforward, as all you need to do is:

Install Jenkins

The Jenkins install is also fairly straightforward as it uses a standard Windows installer.  After the install is complete it will generate a random password for the administrator into a file within the install and provide you with a message as to where to locate it.  You will need that password to do the initial login and configuration of Jenkins.

One you have started Jenkins it will prompt you as to the plugins you wish to install.  There are 1000+ plugins available for Jenkins.  The primary one we're interested in is the Git plugin, which is part of the default set of plugins that Jenkins will recommend for use. You can just accept their recommendations.

Install AutoCompile

Autocompile has a fairly simple install too, and automatically adds the install directory to the system path.

Configure Jenkins

Change the Jenkins URL from localhost to the actual name of the server that it's running on.

 

Create a Repository in Bononbo

You need to be logged in as the admin user to create a repository.  The only thing you have to provide is the name.

Once you're back at the list of repositories you can use the option there to copy the url for the new repository to the clipboard.

Configure the PowerBuilder IDE to use the new repository

Technically what you will be doing is configuring the PowerBuilder IDE to use a local repository and then configuring that local repository to use the new repository as a remote.  The detailed steps are outlined in my earlier article about using GitHub.  In summary, the steps are:

  1. Use TortoiseGit to create a new 'bare' repository in the directory where the PowerBuilder source is located.
  2. Create a small text file (e.g., readme.md) in the directory.
  3. Use TortoiseGit to add and commit the file.
  4. In PowerBuilder, select PGS Git MSSCCI as the source control system for the workspace.  Make sure that "Suppress prompts to overwrite read-only files" is checked.
  5. In PowerBuilder, add the application target(s) to source control.
  6. In PowerBuilder, add the remaining PowerBuilder objects to source control.
  7. In TortoiseGit settings for the directory, configure the Bonobo repository you created above as a remote repository for the local repository.
  8. In TortoiseGit, do a push from the local repository to the remote repository.

Create a new 'FreeStyle Project' in Jenkins

Under the Source Code Management section of the new project, select Git and then provide the repository URL and credentials to connect to the Git server.

Under the Build Triggers, specify any automatic build triggers you want to use.  For this example, I'm going to use "Poll SCM" and configure it to poll every 15 minutes.

Do a "Build Now" on the project

Because we haven't created any build steps yet this won't build anything yet.  What it will do is create a workspace under C:\Program Files (x86)\Jenkins\workspace and populate it with the current source code from the Git repository.

Create ORCAscript and batch files

Create an ORCAScript file to create PBLs from the source code (createpbls.orca):

  start session
  set debug true  
  scc set connect property logfile "createpbls.log"  
  scc connect offline   
  scc set target "pfc_ci\pfc_ci.pbt" importonly  
  scc exclude liblist "pbdom\pbdom170.pbd"   
  scc refresh target 3pass  
  scc close   
  end session

Because Jenkins pulled the source code for us already we don't have to provide source control settings in the ORCAScript file and can use scc connect offline.  "ImportOnly" tells ORCAScript to build PBLs from source.  "Refresh Target 3pass" tells ORCAScript to do a multi-pass compile.  I'm using a sample app based on a recent version of the open source PFC, which now includes a reference to PBDOM.  Therefore I'm using "scc exclude liblist" to tell ORCAScript to ignore that library during the source code import.

Create a batch file that will run the ORCAScript executable on the ORCAScript file (run_orcascript.cmd).

  orcascr170 createpbls.orca

Create a batch file to call the PowerBuilder stand alone compiler.  We're going to need to pass a number of arguments to the compiler.  Fortunately, the application project object in PowerBuilder shows you the arguments you would need to pass to match the settings in the project object.

Using those arguments - modified slightly because we're deploying in a different location - we should have something like this (run_pbc.cmd):

 pbc170 /d "pfc_ci\pfc_ci.pbt" /o "pfc_ci\pfc_ci.exe" /w n /m n /x 32 /p "PowerBuilder Enterprise Series" /cp "Appeon" /de "Appeon Product File" /v "1.0.0.1" /fv "1.0.0.1"

Finally, create a batch file that will copy the generated exe and pbd files into another directory when the build is complete (copyfiles.cmd).

 md c:\builds\%JOB_NAME%_%BUILD_NUMBER%\  
 FOR /d %%a in (*) do copy %%a\*.exe c:\builds\%JOB_NAME%_%BUILD_NUMBER%\  
 FOR /d %%a in (*) do copy %%a\*.pbd c:\builds\%JOB_NAME%_%BUILD_NUMBER%\

This batch files uses environment variables that Jenkins makes available when the batch file is run to create a separate directory for each build.

Create Build Steps

Go back into the Jenkins project and under Build add a Build Step that executes a batch command.

Specify the run_orcascript.cmd file as the first batch file to run.

Add another build step after the orcascript step and point this one at the run_pbc.cmd file.  Finally, create one more build step after the run_pbc one and have it run the copyfiles.cmd file.

Do a Build Now on the project

We're going to test out our scripts to make sure that Jenkins can do the build.  Once you've scheduled a build you should see it being processed in the list of builds.

If you click on the build, you'll be taken to another page with more details, including the ability to view the console output from the running build.

Test the SCM poll

Now that we know the build works, let's see if we actually have continuous integration.  Go back into PowerBuilder and check out an object.  Make a trivial change and commit it.  Then using TortoiseGit, push that change to the Bonoho repository.  Now watch Jenkins and what you should see is that some time after Bonoho has been updated (depending on what you set the SCM polling time to in Jenkins) Jenkins will automatically launch a build of the project.

Next Steps

That gives us the basics of a continuous integration setup.  I'm going to be looking at taking it a bit further.  In particular.

 
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.