Project Build Structure
In the Synergy structure, the project build process is divided into two as Client Build process and Server Build process, which are performed independently (asynchronously).
When a project created in the Integrated Development Environment is built, after going through the Build stages in the visual, it now becomes a self-executing MicroService. The Form and Flow parts of the project are compiled and combined into an image that can be created as a container in the Docker Registry at the end of the Build process. In this image structure;
- Form Engine
- Workflow Server
- Integration Manager Server (DataSource)
modules. When the necessary parameters (mail server address, gRPC connection address, database information, scripts, etc.) are given to this image structure, it can be run independently wherever desired.
In the Synergy structure, there is a User Applications Kubernetes Cluster environment that runs all projects belonging to tenants in namespaces that are dedicated to the tenant and completely isolated from other tenant environments. By creating a Container inside the tenant's dedicated Namespace, projects belonging to the tenant are built within that Container.
After each compilation process, a new version of the project is formed. The container resulting from the build contains the new version of the project and the packages of the old versions of that project in progress. Thus, the result of the compilation can be used with the new version of the project, as well as the ongoing old version of the project can be worked.
The container created after the build process is ready to run in the corresponding namespace. This Namespace can be in the Container scale of the project according to the need. For example; Container belonging to a very heavily used project can be replicated to meet the need as scale in case of need.
Project packages also include the Integration Manager service. This is to ensure that each project uses its own Integration Manager service, and to balance the load on Integration Manager with replication of the project's Container in the event of congestion. This also prevents a poor performance query used in any project from adversely affecting the performance of all other projects in the system.
Thanks to the Monitoring structure in the system, the performance of the queries used in the projects can be evaluated, and the steps that the query travels on the system during its execution can be examined and how much delay is experienced at which step.