What's New in IBM DevOps Deploy 8.1.0: New Process-as-Code (PAAC) Utility

Date: Version 1.0, Jan 8, 2024

Overview

In the second half of 2024, the DevOps Deploy development team created a new and improved process as code (PAAC) feature that enables our clients to edit / modify processes in the editor of their choice without using the visual process designer should they desire to do this.   The process code can be in either JSON or YAML formats.   This new approach makes the process code easier to read and modify in a very popular and well known file format.   The new PAAC capability works with application, component, and generic processes in IBM DevOps Deploy.   For clients using the existing Process-as-Code Compiler capability, this will not impact them, however,  this new feature provides an alternative way to do the same thing should one choose to leverage it.

In this blog post, I will try to provide you with a preview of how it works and how you could setup a git repository where the processes can be checked into source control.   I will also provide an example of a Continuous Integration (CI) pipeline in the tool of your choice.   For this blog, I am using Azure DevOps as my build pipeline.

Getting Started – The Prerequisites

First, in order to get started with the solution, you will need to download the new Process As Code (PAAC) zip package found at this location: https://urbancode.github.io/plugin-docs-paac/downloads/

You can download the latest version.   In my case, I have downloaded paac-2.0.1173150.zip as shown above to my local host.    Unzip the package and you will find the scripts you can leverage with the new PAAC feature as shown below:

Notice there is a download and upload command for application, component, and generic processes.   A user that will be editing processes as code in the editor of their choice will want to have this package unzipped on their local laptop.

Second, your build tool you want to leverage from an CI perspective will need these files so it can perform the upload of your update processes that you check in to a git source control repository.    In my case, I am using a local Azure DevOps Agent and I have unzipped the packaged to the filesystem on that local agent.

NOTE: in the future, we are going to allow an easy way for a cloud-based build agent (like a GitLab Runner or Cloud instance of Azure DevOps) to easily download the PAAC binaries and use them for this operation.

An Example git Repository Structure

For this example, I am configuring the new PAAC feature to work with an application in IBM DevOps Deploy called Process-as-Code-Example as shown below:

Notice this application has two components associated with it (Process-as-Code and Process-as-Code-YAML).  I will setup my git repository so that I can have both my application process and component processes checked into a git repository.  

At a high-level, here is the file structure for my git repository where the top level folder is the name of my application and I have sub-folders for each component:

If you expand the component folders, you will see the component processes and supporting files that are checked in as code as shown below:

With this structure in mind, you might wonder, how do I get my initial YAML or JSON formatted process file at the application, component, or generic scope so I can check it in to a git repository?   Great question!   Let’s move to the next section.

Download your processes in the PAAC code format

To get the initial version of your process file, you will want to use one of the commands listed below based on the scope of your process:

•            download-application-process
•            download-component-process
•            download-generic-process

You can run this from a command prompt in a terminal window on a host where you have the PAAC zip file extracted.   For example, here are the commands that I used to download my application process:

# export PATH=$PATH:/Users/rlange/Documents/git-ado/paac-2.0.1173150

# download-application-process <username> <password> <deploy-url> <process-name>  <application-name> <filename.json || filename.yaml>

The file we be formatted in a JSON or YAML format based on the extension type you provide (.json or .yaml) at the end of the command as shown above.

As a practical example, let’s say we have an existing application process as shown below:

The command to download this process in JSON format would look like this:

# export PATH=$PATH:/Users/rlange/Documents/git-ado/paac-2.0.1173150

# download-application-process admin <password> https://169.xx.xxx.xx:8444/ Deploy-PAAC Process-as-Code-Example deploy-paac.json

You can now edit this file with the editor of your choice.   This is what mine looks like in JSON format using my VS Code editor:

For more information around how to add different types of steps to a process, you can find more documentation here:   https://urbancode.github.io/plugin-docs-paac/

An example CI pipeline using Azure DevOps

For my environment, I have configured an Azure DevOps pipeline that will run automatically when a git commit is performed against my git repository.   The classic pipeline that I configured looks like this:

Here is an example of one of the upload application process step shown above so you can see what it looks like:

export PATH=$PATH:/Users/rlange/Documents/git-ado/paac-2.0.1173150

# -----------------------------------------------------------------------

# Change directory to the application folder (Process-as-Code-Example)

# -----------------------------------------------------------------------

cd Process-as-Code-Example

ls -al

FOUND_CHANGES=false

######

# The -cmin 5 is used to check to changes in the last 5 minutes

######

for name in `find . -name "*.txt" -cmin -5`

do

    echo Changes made to $name

        FOUND_CHANGES=true

done

######

# The -cmin 5 is used to check to changes in the last 5 minutes

######

for name in `find . -name "*.json" -cmin -5`

do

    echo Changes made to $name

    FOUND_CHANGES=true

done

if [[ $FOUND_CHANGES == "true" ]]

then

      echo "Changes were found to the application process.   Running the upload-application-process command..."

      upload-application-process $(deploy-username) $(deploy-password) $(deploy-server-url) deploy-paac.json "$(Build.SourceVersionMessage)"

      echo "Upload of application process was successful"

else

     echo "No code changes found"

fi

Notice that I am using a predefined variable for Azure DevOps called “$(Build.SourceVersionMessage)” so that the commit message is passed as a comment for the new process update that I will push to IBM DevOps Deploy.

I have configured a trigger so that the pipeline will automatically run when a git commit is pushed to the main branch of the repository as shown below:

You could do a similar process with GitLab or other build tools as well.   Of course, you can set up git flow processes where someone would review the update made to a feature branch and then when approved, the changes would be merged from a feature branch back into the main branch.  

Updating a process and triggering the CI process

As an example, I will update my application process so the final step of the process, which was a manual step, is removed as it is no longer required.  

I will then run the following git commands to update the process in the repository:

When I push the change, my Azure DevOps pipeline will begin to run as shown below:

You will then see that the pipeline will upload the updated application process from the git repository to IBM DevOps Deploy as shown below:

You can see it was successful in uploading the update to the application process stored in git to IBM DevOps Deploy.   We can now login to IBM DevOps Deploy to see the update to the application process named “Deploy-PAAC”:

Notice the version changed from 6 to 7 after this process ran.   If you look at the ‘Changes’ sub-tab, you will see the commit message associated with the new change:

The CI pipeline was successful in updating the DevOps Deploy process from the process that was stored as code in git!

This is a simple example of how you can configure your CI to update the processes.   For a production setup, you may want to configure a pull or merge request with an approval before any changes are officially updated in IBM DevOps Deploy by your pipeline.

Summary

For those adopting platform engineering practices in 2025, we are looking to add new capabilities to DevOps Deploy to support these types of features.   As you can see from this blog, the new Process-as-Code (PAAC) utility is very easy to work with and additional capabilities will be coming in 2025. 

As always, our goal is to ensure IBM DevOps Deploy continues to be easy to use while continuing to provide the most diverse deployment support in the market.   More exciting updates are coming in 2025 so be on the look out!