We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.

Skip to content

How to Deliver Applications in Low-Code—The CI/CD Process on the Mendix Platform

Technology

Oct 20, 2020 - 9 minutes read

1116 Improve Your Software Development 416X300
Objectivity Innovative leader in technologies

Our specialty is designing, delivering, and supporting IT solutions to help our clients succeed. We have an ethical framework that underpins everything we do. Our underlying philosophy is that every client engagement should result in a Win-Win and this is supported by our four values: People, Integrity, Excellence, and Agility. Our clients are at the heart of our business and we are proud to form long-lasting working relationships, the longest of which is 29 years. Our goal is to continue to grow our business whilst remaining true to the ethical framework and values on which we are founded.

See all Objectivity's posts
Data Driven Organisation Blog Ebook 416X300

Share

Nowadays, software development is much more than just writing code. It’s a complex logistical process designed to deliver a product as soon as possible. That’s why there are lots of tools and approaches which allow us to improve the software development process. In this article, we will cover two of these approaches: Continuous Integration (CI) and Continuous Delivery (CD), as well as their implementation on the Mendix low-code development platform.

Let’s start with Continuous Integration. The primary goals of CI are to minimise the effort required for merging changes, avoid useless parts of code, and find bugs during early stages of development. The developers should implement and merge changes as often as possible to keep the code updated at all times. Applying this practice could solve many issues that show up during everyday work on application development and make the life of a developer much more convenient.

Continuous Delivery has a broader scope than CI. The main goal of the CD approach is to have the possibility to release the product at any given moment. It allows for delivering a new application version at the end of each sprint cycle. This makes presenting progress to the client much easier. The value of this approach is huge, and it fits in perfectly with the agile philosophy.

What about low-code? Is there room to implement the CI and CD approaches in our projects? The answer is “Yes”. Low-code projects are identical to traditional software projects in terms of background. That’s why we can encounter some of the same issues: problems with integration and regression bugs. They can also benefit from more frequent releases.

You probably have some idea about what CI/CD solutions in low-code projects can look like. Low-code platforms are known for features like one-click deployment, prepared environment, built-in repositories, and many more. This article aims to present the CI/CD approach when applied to low-code from the Mendix perspective.

If we type “Mendix CI/CD” into our search engine, the first result will be the Mendix blog. When you go there, you’ll be able to find a blog article that includes this picture:

Mendix Continuous Delivery

Figure 1. Mendix Continous Delivery, https://www.mendix.com/evaluation-guide/app-lifecycle/cicd

As you can see, Mendix’s Continuous Delivery is divided into five parts:

  • Application Lifecycle Management
  • Build Automation
  • Release Creation
  • Test Automation
  • Application Release Automation

From the abovementioned list, the three middle elements are defined as Continuous Integration.

Let’s go through these points and analyse the provided solutions.

Application Lifecycle Management

In Mendix, all actions related to creating the application are grouped in a Project. This element allows us to plan daily work by using the project management features. There are options to create sprints and stories. Each story has its context where you can add a description and estimation, and divide it into tasks and comments. Moreover, you can track the progress by managing story statuses. When it’s necessary, you can view all stories on a Kanban board which gives a good overview of progress made in the entire project. The stories can be assigned to specific people and changes can be made in Mendix Studio/Studio Pro.

Mendix is also great for managing a team. The platform has multiple predefined roles with a list of suggested access rights for each role.

Lastly, it’s also worth mentioning the code repository—it will contain all the changes made during the development process.

After combining all these elements, we’ll get an environment that enables effective project management for different roles. Business Analysts can define stories. Developers are able to deliver business value and code that can be assigned to the selected user story. And, testers have access to project documentation with all requirements gathered in one place. Moreover, a Project Manager can easily track project progress.

Additionally, Mendix offers a Feedback Management tool. It’s targeted towards users and application testers. We can use it to collect feedback directly from the users. It also enables us to create stories and plans in the Scrum cycle with a single click. This feature facilitates making improvements based on real feedback.

However, in case of a more complex project, where we want to track the time spent on each story, be able to customise the flow of the stories, and prepare reports, the abovementioned tools may turn out to be insufficient. In such a situation, you will probably need to use tools designed specifically for this purpose, e.g. Jira.

Build Automation

Mendix has a built-in version control feature, which saves precise information about all changes made to your project. Access to the exact changes is available only within Studio Pro. The user can review all the changes made by other developers. The app displays information about which component (microflow, page) was changed, who the contributor was, and when the change was made. Tracking is done on the component level, so we will not be able to find as detailed information about changes as in traditional coding.

Technically, this version control feature is based on SVN. It also supports branching and merging. In special cases, we can access the project repository via an SVN client (e.g. Tortoise SVN). The whole Mendix project is one big monolith file, so tracking changes with a SVN client may not be the most efficient approach. However, in the cases of Java classes, CSS style files, or external widgets—it’s good to have this possibility.

In the scope of code quality, code review is a crucial part. From our perspective, this process starts with a peer review performed by a colleague on your team. This is the first step that we recommend taking. It introduces a manual element to the process and enables your colleague to take into account project-specific details. As the second stage, you can use an automatic tool like Application Code Reviewer. This tool will check the code according to predefined rules, including security recommendations.

In the case of many low-code platforms, building and deployment is often a one-click action. In Mendix, when your application is hosted on the Mendix cloud, you can easily deploy it directly to your environment with a single click. To be precise, your code will be committed to the repository and pushed to the Mendix Build Server, then the package will be created and deployed to your development environment.

Release Creation

Just like package creation, releasing your application is a one-click process in the Mendix Cloud. There are two necessary steps in the release process. The first step is to upload the package that was created in the building phase to the selected environment. The second step involves restarting the application. After the restart, the new version of the application will be up and running on the environment. The platform will handle database structure changes. It will also map existing data to the new structure.

Moreover, the Mendix Cloud enables us to manage the configuration of our app in one place. The platform allows us to securely store environmental variables in the Mendix Portal. The variables are set individually for each environment. Not only can you define custom settings related to the application, but you’re also able to adjust your application environment, e.g. by managing scheduled events, firewall settings, the preferred maintenance window. Furthermore, it’s possible to add runtime variables and configure log levels.

Application releases are not limited to the Mendix Cloud. You have plenty of options—you can run a Mendix application in your private environment or on public cloud. For more on this topic, check our article on deploying and hosting Mendix low-code systems.

Test Automation

When our app is in the cloud and we want to proceed with the final release, we should perform tests on the next version. This can be done on a few different levels—such as unit testing, conducting integration tests, or automated UI testing.

The configuration of unit tests requires an external module which can be easily downloaded from the Mendix App Store. This module allows for creating and running unit tests. In Mendix, unit tests are part of the solution and they’re run every time the application is restarted. As such, you need to create unit tests in a way that won’t affect the data in your application. This issue can generate additional risk in case of a production environment that should be included in the project.

As for integration and automated UI tests, there are free built-in Mendix tools that can deliver these features. You should probably start by looking at Mendix Automation Test Suite. This add-on is designed to help with testing Mendix applications from different perspectives. It offers functional, regression, availability, security, and performance testing. ATS is built on Selenium, a supporting framework for case recording and data-driven testing.

Moreover, you can use any tool you know for test automation, no matter if it’s Selenium, SoapUI, JMeter or anything else. Each of these tools has its pros and cons. You’ll need to learn how to test applications created in Mendix, e.g. how communication between the browser and the server is performed.

Application Release Automation

The last stage of the whole process is application release automation. We’ve already covered many of the possibilities of automation in the Mendix platform. This step greatly depends on the configuration of the solution. Mendix offers three APIs to support automation flexibility:

  • Team Server API – provides information on the application models
  • Build API – you can use it to manage and create deployment packages with Mendix Build Server
  • Deployment API – allows you to manipulate Mendix Cloud environments.

With those three APIs, you can automate the entire release process. It can be further supported with multiple different tools that are available on the market. The examples include Azure DevOps, Jenkins, TeamCity, and more.

Imagine that you want to automate the release process of your application that will be hosted as a Docker Image in Azure. In that case, your flow can look like this: after committing changes to the Team Server, you build the Docker Image. Next, the image is released to the Development/Quality environment. That’s where all automated tests take place. If everything’s fine, the image can be stored and transferred to the next step— the Test environment. Later, we can promote it to UAT, wait for the customer acceptance test to be performed, and, finally, deploy it in the Production environment. The aforementioned actions can be easily implemented using Azure DevOps. Azure DevOps is also recommended for the provision of the application infrastructure. High automation allows us to create a Quality environment exclusively for the test runs. After conducting the tests, we can remove it entirely.

When the application goes live, we have to set up the monitoring and alerting. The Mendix Cloud environment includes a built-in application monitor. It provides application statistics, such as:

  • the number of handled external requests,
  • user accounts and login sessions,
  • JVM object heap,
  • JVM process memory usage,
  • application node operating system memory
  • and more.

It also produces some database statistics like the number of database queries being executed, database table vs. index size, number of database mutations, etc., and presents them visually. The application operator can analyse the metrics and find potential issues with the code. For example, if database usage is high and there are no active users or operations, this means that some unexpected processes are taking place. At the same time, you’ll receive a pre-configured alert that will notify you whenever something isn’t working as intended.

Each time you’re deploying an application outside the Mendix Cloud, you’ll need to configure your tools for monitoring and alerting specifically for that platform. Besides, you can utilise external tools like Azure Application Insights or Mendix Application Performance Diagnostics. With these additional tools, you’ll be able to get more detailed information about your environment.

Summary

In this article, we presented the different possibilities of implementing the CI/CD approach in the Mendix environment. Building your application directly in the Mendix Cloud will provide access to one-click deployment and all the built-in features of the platform. There also are plenty of options in terms of customisation, however, some of them may require additional work. Nevertheless, Mendix is a flexible low-code platform that allows you to adjust the CI/CD process to your needs.

About the Authors:

Michał Gogół

Rapid Application Developer

He has over 2 years of experience with delivering web and mobile solutions. Certified Mendix Advanced Developer. Additionally, he has skills in React.js that allow him to build custom widgets for Mendix. An enthusiast of IoT solutions and all kinds of electric vehicles.

Michał Jankowski

Solution Architect, Low-Code Practice Lead

He has over 13 years of experience in creating software for the biggest international organisations. During this time, he developed desktop, web and mobile apps. Michał currently is an expert in cloud solutions and low-code platforms. His hobbies include travelling and photography.

Data Driven Organisation Blog Ebook 416X300
Objectivity Innovative leader in technologies

Our specialty is designing, delivering, and supporting IT solutions to help our clients succeed. We have an ethical framework that underpins everything we do. Our underlying philosophy is that every client engagement should result in a Win-Win and this is supported by our four values: People, Integrity, Excellence, and Agility. Our clients are at the heart of our business and we are proud to form long-lasting working relationships, the longest of which is 29 years. Our goal is to continue to grow our business whilst remaining true to the ethical framework and values on which we are founded.

See all Objectivity's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle