OpenEdge DevOps Framework

Since we are a partner of Progress we cannot escape the newly promoted build scripting language Gradle and so I was asked to take a day to evaluate Gradle. To start with, I am a bit biased, I work with Ant and PCT for more than 10 years, the last years I am using more and more Groovy, but I like the Ant XML style, which makes it very clear it is a build scripting language and not a programming language. We have Ant, PCT, Maven, Groovy and why would we need yet another build scripting language?

Gradle is delivered with Progress. At least there is a wrapper in the DLC, which starts to download the supported version of Gradle. Also when writing the first Gradle script with the Progress plugin, the plugin is automatically downloaded. That is a welcome change from using Ant or Groovy and making sure that all the .jar files of the correct version are in SCM and so on, as long as the build environment has an internet connection, that is. 

When starting the Gradle wrapper script with –help, immediately the command line options for executing a script parallel (with an automatically determined optimal number of threads) or no parallel (for debug purposes) draw my attention. In Ant I had to include the maximum number of threads per core in a properties file and tailor it to the target build server environment. For disabling all parallel execution in an Ant script for debug purposes, I would have to use a java startup parameter which overrules a property. 

When running Gradle it becomes clear that Gradle generates a number of default output and working directories, another task I usually have to do by hand. Looking at the dependency management and the command line options Gradle looks DevOps engineer friendly. 

Just like a Jenkinsfile, Gradle is sort of a wrapper around Groovy. Sections of your script are interpreted and executed by a Groovy script, which gives the really neat possibility to unleash the full power of Groovy in a Gradle script. At the same time, that introduces the risk of unmanageable over complicated spaghetti build scripts. 

The smallest entity is a task and tasks are based on a task type. A task type is like a function prototype and it is of course possible to create your own task types. You can set dependencies between tasks, in the definition of a task or separate in the code, which is of course a must for a nice build script flow.  

Probably when you managed to read until here in the blog, you are probably well aware of the capabilities of Ant and PCT with regards to building and deploying OpenEdge. The OpenEdge DevOps Framework brings the strength of PCT to Gradle. And while it looks promising it is not quite there yet. The possibilities of the OpenEdge DevOps Framework are nowhere near the full capabilities of PCT yet. Some properties for tasks seem to be missing and the tasks available are only a very limited subset of the PCT tasks. It is possible to invoke PCT tasks from Gradle via Ant though.

To start creating a Gradle build, you must create a build.gradle and build.config in the root of an OpenEdge project, where the .propath is located. The OpenEdge DevOps Framework will use the .propath file. 

Including the OpenEdge DevOps Framework

Displaying a BOM, with the PCT version included, invoked via Ant. The openedgeVersion variable is available because of the task type ABLCompile. 

Gradle looks promising. It seems to have the possibility to take the orchestration of build tasks to a higher automated level than Ant while at the same time just being able to use Groovy code which is stronger than Ant. You can make nice structured, maintainable build scripts, but there is the risk of over complicated build scripts. The OpenEdge DevOps Framework is not mature yet, but it has potential.