Menditect offers Menditect Test Automation (MTA) as a Software as a Service (SaaS) solution. In this “hosted” model we maintain, monitor and upgrade MTA for all our customers. Menditect runs the hosted version of MTA in the Mendix cloud. This has the advantage that MTA customers can use the service without any hassles and have no need to maintain and monitor the environments. Each customer has its own tenant so that they do not share data and computational resources with other customers.
As of this week Menditect also supports deployment of MTA on your own servers or Mendix (private) cloud. In this blog we describe why we offer this option, what the architecture is and how you can deploy and update MTA.
Although the Mendix cloud is the preferred deployment model for most Mendix customers, Mendix also offers on premises deployment and deployment in your private cloud. In many cases the on premise apps are not accessible via the internet. Therefore, testing them with MTA running in the public Mendix cloud is not an option. MTA is a Mendix application and can therefore run as a Mendix app on the customers private cloud or on premises deployment. Of course, in such a case the Menditect customer is responsible for monitoring, maintaining and upgrading MTA.
Recently we also got demand from customers that use the Mendix cloud to run MTA on their environments. The prime reason for this is the sensitive nature of their (test)data. Although Menditect promotes the use of synthetic an anonymized test data, we also know that in reality test data is often a (modified) copy of production data. Of course it is possible to sign contracts about data privacy and have all the audits and security measures in place. However, everything becomes much easier if Menditect only provides the functionality of MTA and the customer manages the data. Therefore the “on premise” version of MTA suitts also customers that run their apps in the Mendix cloud, but would rather manage the test data themselves.
In order to run MTA on your own environment you need to be aware of the MTA architecture and network setup.
MTA logical architecture
In the above picture we show the logical architecture for MTA. This architecture is valid both for the hosted version and the “on premise” version of MTA. MTA integrates with both Menditect license server and Mendix cloud services (e.g. team server) as with your test environment. Integration with the Mendix cloud is set up via API keys and Personal Access Tokens that can be revoked by the customer at any moment. Integration between MTA and the test environment is only possible if the MTA plugin is installed and has an active user on the test environment. The customer is therefore always in control of whether MTA can execute test scripts. The (sensitive) test data is only shared between your test environment and the MTA environment. It is not shared with the Menditect or Mendix cloud services.
MTA network architecture (on premises)
In the picture above we show how MTA can run on your own network and how it connects with the Menditect and Mendix cloud services. As becomes immediately clear from this picture is that the (on premise) environment on which MTA is running needs to have an outgoing connection via port 443 to the internet. No test data is shared over these connections, but Menditect needs to have access to the license server and the Mendix models of the applications under test to work. Since MTA is now running in the customers network, all test data remains in the customer network and is never shared with Menditect.
If you run MTA on your own environment Menditect publishes new versions of MTA as an MDA file (this is the file format Mendix uses to deploy Mendix applications). You can upload these MDA files directly to the Mendix cloud, run them in the Mendix Service Console or create a Docker container from it. In the MTA documentation you can find the values of the constants for your environment.
Menditect releases roughly every month a new version and once in a while an intermediate patch. Each version or patch can contain migration scripts to migrate old data to a new version of the MTA data model. Therefore we strongly recommend updating MTA as soon as a new version is available. If, for whatever reason, you decide not to upgrade immediately you have to upgrade step by step if you missed to deploy a MTA minor update. So, upgrading from MTA 1.6 to MTA 1.8 is only possible by first upgrading to from MTA 1.6 to MTA 1.7 and then from MTA 1.7 to MTA 1.8. We will publish the upgrade paths as part of our release notes and documentation.
With the new option to deploy MTA on your own Mendix environment we can both serve:
These new options broaden the use of MTA for different types of Mendix apps and allow us to serve customers that would not use MTA in the hosted version. Menditect is continuously improving the functionality and capabilities of MTA and this yet is another step in our journey to make testing of Mendix apps easier and faster.
| info@menditect.com | |
| +3185 - 4010494 | |
| KvK: 82975795 | |
| Volg ons op LinkedIn |
Enter your information and choose a day and time when you would like to receive the demo (1,5 hrs).