Publish changes without deployment#
Publish changes without deployment
The application using Hyperon is updated without the need of releasing new version.
Hyperon Studio is web application made for implementing structure, parameterization and business logic by analysts and business representatives.
Hyperon Runtime is a library responsible for providing configuration and data for client’s application without losing performance. This aspect is achieved by mechanism of storing data as indexed matrixes, in cache memory and fetching them only when changes in Hyperon Studio are detected.
Works with SQL database
Hyperon application works perfectly with SQL databases: Oracle, MsSQL, Postgres, H2 and HSQL.
Domain Driven Design
With Hyperon Studio user can create problem using domain driven design. Domain is functionality responsible for definition of custom components and objects that reflects simplified reality. Defined domain types can be used in Hyperon Studio and then other users can build solution based on that.
There is no limit to number of users working simultaneously, so every user has his or her own session (register of changes) and works on public environment applying his private changes. Those changes can’t be used by other users until they are published.
While developing configuration in Hyperon developer may check how user’s unpublished session influence client’s app behavior by using dev_mode. Developer may set Hyperon Runtime on selected user session (by using user-name) and launch client’s application locally.
Hyperon Studio provides testing module for parameters, functions and domain elements. It means that every change done by a user may be verified before publishing, without developers, since user don’t have to deploy client’s application and switch to developer mode to run simple tests. Within that module user may check prepared test cases or run mass tests for multiple inputs and outputs within one parameter or function. All data needed to run those tests can be given from the level of testing module or by importing prepared excel file.
Hyperon Studio provides controlled way of defining inputs, which might be complex structures, called Hyperon Context. This context is referred to input data of proper structure and values, that are required for configuration to produce values.
If you want to persist context information in any way, you can use the Persistence Engine. Context structure with values can be easily stored within any database (same as application or separate). The engine can be used out of the box and speed up development process.
Usually process of development does not include only one environment. That creates a need to easily update environments. Hyperon provides two mechanism (superpack and snapshot) to do such migration, that may be done globally or just on selected profile. Depending on users’ needs that might be done by updating from one parameter up to whole configuration. Snapshot is functionality that may be used by every user since its build mechanism is simplified to a few fields, Superpack is more advanced feature and it is dedicated for advanced users.
Inside Hyperon Studio multiple profiles might be defined, that allows to use one environment for as many configurations as needed. Every profile contains its own definition of inputs and outputs for client application, and its own parameterization. What does it mean for user's application architecture? Only one Hyperon Runtime Library is needed even in multi-profile environment. Application can switch between profiles in runtime, restart is not necessary.
Hyperon Runtime provides API for developers to work within defined domain. Data which have to be provided by developer are: inputs to implemented domain and properly implemented output, to receive result value. Developer which takes care of application’s backend doesn’t have to go into business logic in between inputs and outputs, Hyperon is responsible for that.
All created elements as functions, parameters and Domain Objects (only those of Type with business role : PRODUCT) might be versioned, every version may be independently edited. Versions may differ not only by matrixes and functions, but also by domain configuration.
When versions are created there is a possibility to create the Timeline - a schedule defining when which version of configuration should be available for the application.