3 tips for integrating low-code platforms

Low-code development platforms allow people to create applications using graphical user interfaces (GUIs) rather than code. They are capturing attention because they help business users create the applications they need quickly, even without any programming knowledge.

[ Learn best practices for implementing automation in The automation architect's handbook. ] 

Thousands of companies are using low-code platforms to develop business-critical solutions. Anyone who has worked with low-code tools long enough knows how reliable and easy to use they can be. However, once your business has matured to a certain level, your company's ecosystem may require nonstandard practices that basic low-code platforms can't address.

Low code is great for large-scale development, but there are situations when you need to borrow some hacks from core development practices to achieve your goals. This can help you significantly improve a solution's quality and eliminate routine activities. It can also help reduce development team effort, thus making a project more cost-effective.

In this article, I share how I solve complicated development challenges using a low-code platform and some unconventional tips.

The scenario

I was asked to help several teams who were developing a large bank's customer relationship management (CRM) system using a low-code platform. The group consisted of more than 50 people in various roles—developers at different levels, quality assurance (QA) specialists, business analysts, and engineers. The bank's activities span multiple business areas, including retail lending, lending to legal entities, and mortgage lending, and each team works on functionality for its business line. Releases are installed independently, but the teams were creating one universal application for all business lines.

This team's main difficulties related to the quality of releases and the complexity of their installation.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

Assessing application quality

Many low-code platforms have a lot of built-in tools to facilitate an application's quality. There are landing pages that display the complete application's quality, there are ways to review the developed functionality in branches, and you can track the deployed functionality by tests.

Unfortunately, when several groups work on the same application, the functionality developed by one team may implicitly affect the work done by another team.

It's not always possible to conduct full-fledged cross-review and regression testing, so a logical solution is to turn to the best practices in core development. The Java development world offers mature (evolving over 20 years) application quality-control practices, so I thought it reasonable to bring something from the Java world to low code.

I decided to try the following things:

• Unit testing in Java
• Build quality control on the pipeline
• Code review with external tools

Here's what I learned from my unit testing, build quality control, and code review tests.

[ Learn how IT modernization can help alleviate technical debt. ]

1. Unit testing

The main challenge was a lack of complex integration tests that could check the operation of many business rules cumulatively. This isolated their work from interacting with external systems that may not be available. Such testing functionality is often missing in low-code platforms, so good expertise in Java allows for solving such problems.

Using the many Java unit testing features, my team quickly wrote the necessary unit and integration tests to run and identify problem areas on every build. The Java toolkit is vast, so you can set up tests flexible enough to cover all the necessary business scenarios.

2. Build quality control

I wanted to achieve automatic quality control of a potential release after the build. My team added new warnings and guardrails to our development environment. We created a special step in the pipeline that checked the compliance of the build with the established quality criteria. We tested the following criteria:

• No warnings with the developer's explanation missing
• No warnings of a moderate level and above
• No warnings of type performance
• The unit test covers over 85% of new features

If the build didn't meet those criteria, the pipeline automatically rejected it.

3. Code review

Out-of-the-box code review capabilities are good when all the codebases comply with the vendor's best practices and when an application has a minimum of custom improvements. The classic code review tools from the world of core development seem to answer all of these needs.

For all low-code elements from the platform, we made convenient text representations, which highlighted the changes made with the new versions. This allows a reviewer to leave a comment on a specific line of code, which makes reviewing comments faster and more accurate.

Automating the build pipeline

Most low-code platforms have continuous integration and continuous development (CI/CD) solutions, but they often are not as flexible as businesses need. But what if your release is not only a new release of a low-code application but also about various changes in a database? This can include running complex logic for migrating data and following instructions from the environment's administrators to set up runtime-specific variables.

Configuring such a build is very difficult. My team decided to customize its pipeline, borrowing approaches from the Java world. Based on the configuration file, the build server unloaded the required artifacts from the platform and ran the necessary SQL scripts and migrations. This approach removes manual steps from the installation process for a new release and minimizes the number of human errors.

Conclusion

All in all, low-code practices provide wide opportunities to benefit business. However, even if you lack the built-in features of a low-code tool, you can always connect something from the world of core development and succeed.