Getting Groovy with FlexDeploy for Customized CI/CD

FlexDeploy is an enterprise DevOps and CI/CD platform that has over 100 out of the box plugins and integrations to applications, tools, and middleware technologies. As powerful as that is for consumers of those application, tools, and middleware technologies, every enterprise has assets certain to fall outside of that domain.

FlexDeploy recognizes that and has made significant investments to enable customers to roll their own solutions, plug them in, and still take advantage of the many features the platform has to offer.

Three important building blocks supporting this extensibility are:

• Technical plugins
  • Apache Ant
  • Apache Maven
  • Unix and Windows Scripting
  • Scripting Languages
  • REST
  • WLST for WebLogic
  • And more…
• An SDK enabling customers to create their own plugins
• A unique “Partial Deployment” model, which enables collections of objects (packages) to be built and deployed

The partial deployment model is useful when the build artifact does not represent an “application” which can be deployed in its entirety (e.g. a Java web application or WAR). For large scale commercial off the shelf (COTS) applications like an ERP (e.g Oracle EBS) or CRM (e.g. Salesforce), building and deploying the entire application does not make sense. These applications are made of thousands of files and are often managed by large development teams. Instead, there is the requirement to bundle subsets of objects/files in some collection and manage its lifecycle thought the pipeline.

That is where partial deployment comes into play. Files representing the application are reverse engineered into a catalog, and those files are bundled into packages. The build output of the package becomes the artifact, and its lifecycle is managed across the software delivery pipeline.

In this article, we will explore how you can use FlexDeploy’s integration features to build a custom solution using a scripting language.

A Groovy Example

As an example, let’s assume we have a Git repository containing a third-party or homegrown application, consisting of several hundred files. The architecture of this application requires changed files to be copied to the target server and some API to be executed to load it into the backend store. For our example, we will assume that the API is available in Groovy or Java, but the same technique could be used for Jython, Python, shell scrips, REST, or fundamentally any other API.

For simplicity sake, the API to deploy the file is contained in a Groovy class called DeploymentService. To call this API, we simply instantiate the service and call the deploy method, passing the filename.

import com.example.DeploymentService;

DeploymentService service= new DeploymentService();
deploymentService.deploy(SOURCE_FILE);

Unfortunately, FlexDeploy has no plugin for the fictitious DeploymentService API. All is not lost, however.

Implementing the groovy script in a deploy workflow is as simple as dragging the executeCodePartial step of the Groovy Plugin onto the canvas of the workflow editor. This operation will execute the Groovy script once for every file in the package, with the SOURCE_FILE variable being the path to the file.

[notification type=”alert-info” close=”true” ]Having the Consumes Artifacts option checked is paramount as this tells FlexDeploy we require the artifacts/files saved during build.[/notification]

Next, configure a Partial Deploy Project to use this workflow and massive deployment fun can ensue.

Seeing it in Action

Initiate a package deployment for the project and upon completion you can view the status of each file:

As you can see, all of the files deployed successfully without errors. And that’s it! We just deployed individual components of a larger application separately through Partial Deployments and Groovy.

Filtering Files

In the previous example we deployed every file in the same manner, via the DeploymentService.deploy() method. However, what if we had a case where we wanted to deploy different files through different APIs? Or skip files entirely?

In the below example, we’ll do just that. Any non-SQL files are conditionally skipped based on the FILE_EXTENSION variable. More importantly, the skipped files also have the status updated to SKIPPED.

import com.example.DeploymentService; 

// only deploy the file if it is a sql file
if(FILE_EXTENSION == "sql")
{
    DeploymentService sevice= new DeploymentService();
    deploymentObject.deploy(SOURCE_FILE);
} else {
    packageFunctions.setObjectResultStatusSkipped();
}

Initiate another deploy and take a look:

Consequently we can see all 3 files with a SKIPPED status.

This was a brief demonstration of the flexibility of the Groovy Plugin using partial deployment. For more tips and tricks on what you can do, see the official documentation.

Other Options

Groovy not your thing? No problem! We have plugins that support partial deployments for whatever scripting language you prefer and we are always coming out with more.

• Shell
• Windows Shell
• Jython
• Powershell
• WLST
• Python (Coming Soon)

In summary, whether through Groovy or another scripting plugin, there are always solutions if you are willing to roll up your sleeves and hash out a few lines of code.