Best practices for low-code integration within dev pipelines

An example of low-code integration challenges

An example can help illustrate some of the main challenges a development team faces related to low-code integration.

Let's say a grocery store develops a mobile shopping list application. The idea stems originally from the marketing department, and the app is intended to streamline customers' grocery shopping experience. The company uses low-code tools to start the app development process.

However, the shopping list application doesn't exist in isolation. It uses APIs to reach into the company product catalog, enabling users to search for products and add them to their shopping list. The app also ties the product back to an aisle number in a specific store so users can organize their list by aisle. The APIs that enable this functionality change over time and aren't versioned.

In addition, the project director wants the tool tested in the staging environment. In this example, there are a few points of integration. The API is one, but the build is another, which may be more crucial.

Once the marketing department finishes the project, someone needs to keep the app working as the software around it continues to change.

Integration points for low-code tools

Most CI/CD tools assume a simple build paradigm. The tool, such as Jenkins or CircleCI, runs on a server, physical or virtual. That server runs on an OS like Linux or Windows. A build checks out the code from version control and executes a build script. The build script returns a zero (success) or one (failure) to the OS and can write results to STDOUT or STDERR. That enables the tool to paint the step red or green and, perhaps, have some text. If the script produces test results in a file, a post-build step can connect those test results with the build.

The problem with this paradigm is that many low-code tools don't have a command-line runner. If they do, it may be for the wrong OS. If they do and it is for the right OS, they might not have a mechanism to check in, commit, peer review and approve changes. Instead, the tool might just have a save button. This means, if CI/CD kicks off a build, it might include the latest untested work of a developer.

All these concerns create questions about the architecture before choosing a low-code tool. A low-code tool that has no concept of promoting code is best with a pipeline that is separate from the main codebase. However, both the low-code tool's pipeline and the APIs themselves could have contract tests, in which the APIs are expected to work a certain way. If the API changes in a way that breaks the shopping list app, the company would want to block the release of the software. This means one contract test is expressed in two places: the API and the low-code tool itself.

Some low-code tools, such as Mendix, do have an API to access the build, and others have a command line. Canonic is a low-code, back end-as-service tool with the low code expressed in GitHub, which enables code review, testing and pull requests. With Canonic, the build pipeline can run locally, pass and then be merged, like in traditional software development.

However, most low-code tools put the code in their own walled garden, up to and including their own CI/CD platform. Development teams then end up considering a tool vendor that provides both low-code tools and other enterprise software, such as Microsoft, Oracle or Salesforce. That way, they have the best chance of seamlessly running the two together.

Integration testing and maintenance

At this point, there are two options for our shopping list application: call the low-code build from the existing CI/CD pipeline or maintain a separate build process.

Both options may involve tests that call APIs in the legacy software. Those APIs need to have known-good responses. Testing teams need to create code to call the APIs. To do this, they can use an API test tool, such as SoapUI or Postman, or create small custom scripts in a production programming language.

Pytest is a Python-based integration testing tool that creates tests and scripts that call APIs. If the team doesn't know or use Python, it should use another tool or programming language it's familiar with. A final element to consider is the password and login to these tools. Most APIs require them, and the Python scripts that call the API need to know them as well. Consider a secrets management application, as you would for passwords for other enterprise software.

Once these scripts exist, someone needs to maintain them. The best team to do this is the same team that manages the traditional CI/CD system. That could be a DevOps group, an internal architecture group or, possibly, the line programming team.

However, with the example shopping list app, the company doesn't have a central DevOps team. Instead, the development teams support the systems they are responsible for. The marketing team built the app as a one-off project. The project director will likely select the product search API team to maintain the build going forward, which is probably the best bet.

With these ideas, an astute team can support the low-code project while timing releases with new code, which ensures both systems are reliable. This demonstrates that, with a little work in advance, teams can minimize low-code integration challenges.