In a surprising number of OpenEdge estates, the true source of the application is "whatever is on the production server", and the build process is a set of steps one developer knows by heart. That works until the developer is on holiday, or retires, or the upgrade needs every program recompiled against a new release. Putting the ABL codebase into Git and building it automatically is one of the most useful modernization steps there is, and it changes nothing the users can see.
Step 1: find the real source
Start by gathering every place source code lives: the development PROPATH, copies on test servers, anything in an old version control system, and the production server. Compare them. You are looking for:
- programs that exist in production but not in development;
- programs with different contents in different places;
- r-code in production with no matching source at all;
- include files and shared libraries outside the main tree.
R-code without source is the most important finding. Each case needs a decision: find the source, rewrite the program, or confirm it is no longer used.
Step 2: make one repository
Create a Git repository with a clear layout: application source, include files, database definitions, configuration templates and build scripts in known places. Add a .gitignore that excludes r-code, logs and local settings. Commit the source as it is today, without tidying, so that the first commit is an honest record of what was running.
Database definitions belong in the repository too. A data definitions dump of each database's schema, committed alongside the code, means schema changes can be reviewed and traced like code changes.
Step 3: compile from a clean checkout
The key test is whether the application can be built from the repository alone, on a machine that is not a developer's workstation. Write a build script that:
- checks out the repository;
- sets the PROPATH;
- connects to a database built from the committed definitions, or to the schema the compile needs;
- compiles every program and saves the r-code;
- reports every error and warning, and fails if there are errors.
Expect the first attempts to fail. Hidden dependencies show up here: an include file only on one machine, a program that assumes a particular PROPATH order, compile-time references to tables in a database nobody mentioned. Fix them in the repository, one at a time. When the clean build succeeds, you have something most estates lack: proof that the running application can be rebuilt.
Developers who use Progress Developer Studio for OpenEdge can keep using it; the build script is what defines the official build. Many teams drive the compile with Apache Ant tasks or a build tool of their choice, run under the OpenEdge runtime.
Step 4: run it automatically
Once the build works by hand, run it on every push to the main branch with whatever CI service your organization already uses. The build machine needs an OpenEdge development licence suitable for compiling; check your licensing before setting this up.
A good first pipeline does three things:
- compiles everything and fails on errors;
- publishes the r-code as a versioned build artifact;
- records which commit produced which artifact.
Step 5: add tests where they pay
ABLUnit, the unit-testing framework included with OpenEdge, lets you write tests in ABL. You do not need to test everything. Start with characterization tests around the logic that matters most and changes most often, such as pricing, allocation and posting routines. A characterization test records what the code does today, so that a later change can be checked against it.
Add the tests to the pipeline so they run on every build.
Step 6: deploy what was built
The last step is to deploy the artifact the pipeline produced, rather than r-code compiled somewhere else. Even a simple script that copies a versioned build to the test server, then the same build to production after sign-off, is a large improvement. Rollback becomes "deploy the previous artifact".
Why it helps an upgrade
An OpenEdge version upgrade means recompiling the whole application against the new release. With a clean build in CI, that is a pipeline change: point the build at the new release and see what breaks, long before the upgrade weekend. Without it, the recompile becomes an archaeology project in the middle of the upgrade.
Getting started
Most of this is patient work rather than difficult work. The hardest part is usually the first step: finding out where the real source is. If you want an outside view of how far your estate is from a clean, repeatable build, that question is part of every assessment we run.
Planning a move off a retired release? The OpenEdge Estate and Upgrade Readiness Assessment reviews your release position, database, AppServer topology and customizations, and ends in written findings, a conversion risk register and a sequenced plan. Tell us about your estate.