Continuous Integration/Continuous Development in the context of Intelligent Business Automation and Low-Code

Low-Code and Time to Market 

When it comes to time to market in software development, an agile development process, cross-functional teams, adapting the scope, using a low-code platform, and continuous integration and continuous delivery (CI/CD) are important topics. While most of these topics can be achieved either by organizing teams in a different way or training, CI/CD is a technical aspect. CI/CD can normally be achieved with version control, automated testing, and automated deployment. This approach feels native in software development itself, while -coupling it with a low-code development platform brings a new challenge: in addition to the developed code there are models defining the process and behavior of the execution. 

Flowable Work, a leading Intelligent Business Automation Platform, already includes a model driven approach through low-code. One of its components, Flowable Design, it’s a tool that allows you to create models of cases, processes, and forms with advanced editing features, making modelling easier and more consistent. 

To ensure consistency, Flowable has already integrated versioning in its products. This helps us to run different versions at the same time and migrate business related information in case we updated our business model. However, this is fine in one environment, while you still need to propagate changes between different environments.  

For source code this is done with a version control system like Git, a build server like Gitlab or Jenkins. While those tools are a great fit for source code, there is no native integration into a low-code environment.  

Testing with Low-Code Development Approach 

An additional challenge faced in developing low-code models is testing. While automated tests in software development are common, writing tests with Low Code environments is more challenging. Normal unit and integration tests are often written as source code in the same programming language than the application as well or are executed by a test system. However, normally business modelers are neither Software Engineers nor Test Engineers. They mainly know their domain, have learned how business process can be modeled with the OMG standards BPMN, CMMN, and DMN.  

Flowable Work allows business process modelers to execute processes, interact with them, and refine them. In addition, Flowable Inspect, allows business modelers to test the models and build automated tests out of the Flowable Inspect user interface. Test definitions can be recorded and replayed at any time to validate changes to process or case models. 

Setting up a CI/CD Pipeline in a Model Driven Approach 

There are several environments in a software project, normally at least three. Starting with a development environment, continuing with a quality assurance (QA), and finally the production environment. Software code is normally promoted in an automated way using a version control system, a CI/CD server, as well as an artifactory to store artifacts long-term. Typically, Software Engineers are writing source code and tests on their machine, committing the source code to their version control system and everything else is happening automatically. The CI/CD pipeline ensures that automated tests are executed before new models and source code can be released to higher environments. This ensures the quality of the system/application exposed to the customer. There might a person involved pressing on a button to do the releases to the QA or production environment. But it’s important for efficiency that there is no log-in to a server and executing a manual deployment, everything needs to be automated. With business process models, there are often additional steps: Software Engineers are exporting them from the modelling application, placing the artifacts on the Source Code and then the deployment can happen. This step is simple, however it’s repetitive and a step which is normally done by Software Engineers. 

Flowable Design allows to publish the models directly to your Flowable Work installation. This is helpful for initial testing, might also be helpful in production in case customers are allowed to do simple changes. However, often the process and case models are fixed and should not be changed once everything is ready for production. A deployment to multiple environments in Flowable Design is possible, but typically you would like to archive the artifacts before the actual deployment. 

This process can be completely automated.  

The Flowable APIs allow defining a custom publish target and then use the Flowable APIs to acquire the required information. Using an application orchestrating the publish to a version control system, helps then to aggregate all the required information for version control and publish the content to a version control system. Once a commit is done, an automated pipeline can be triggered. The pipeline can use a Flowable installation to automatically execute the tests, bundle the artifact, publish them to an artifactory and do what we normally do with source code. Test results can be visualized. Since everything is versioned, we can also tag versions for deployment to different environments and ensure that we always know which state of the models is deploy to which environment. 

A Deployment Example with Flowable Work 

Looking at a Flowable environment, we can deploy to different targets. After the initial deployment on the default target, a publish to our Deployment Pipeline can be done: 

Here, we can also define our own deployment target which then triggers in the background a git commit with all our models included: 

Once the git commit is done, our pipeline can be triggered automatically: 

This pipeline will bundle the installable artifacts for a Flowable application and execute all the tests in a dedicated test environment. The test result is recorded and can be viewed inside the Jenkins pipeline: 

Since all the information is indexed by Elasticsearch, it’s easy for the pipeline to also produce a model coverage report. This is exactly the heatmap which is generated by Flowable out of the box. In addition, the result of the heatmap endpoints can be used to visualize which elements are covered and which not: 

Conclusion 

Modeled business processes seem to be at first out of the context of classical software deployment. They are XML artifacts which are created by a less technical person outside of the scope. With this in mind, Flowable Inspect was developed allowing to have test coverage also for them. With a CI/CD integration it becomes possible to automate the test execute, version on a classical version control system and propagate changes to upper environments. On top of it, it is possible to build management reports regarding test execution and test coverage.  

This way, here at Flowable we managed to combine two relevant time to market aspects, bringing the low-code development platform Flowable Work together with CI/CD.