Evaluation Guide

Model deployment

A Genus application, built with the Genus no-code platform, uses an "app model" to define data, logic, and user interactions. Users interact with the published app model, and updates are deployed immediately by simply publishing a new version, ensuring fast, reliable, and cost-effective updates without complex executables.

  • Genus uses a blue-green strategy for model deployments.

    • The blue environment and the green environment are parallel setups, each capable of hosting your application (your app model). These environments are interchangeable, with one serving as active (handling end-user traffic) and the other as passive (used for testing updates) at any given time.

    • When deploying a new version, the updated app model is first deployed to the passive environment (green if blue is active, or vice versa).

    • After successful testing, the environments are switched: the passive environment goes live, and the active one becomes passive.

    This strategy minimizes downtime and deployment risks by:

    • Allowing comprehensive testing and verification of the new app model in a controlled environment before routing users.

    • Enabling quick rollback by switching back to the previously active environment if critical errors occur.

    The app model is continuously developed in a third environment, named origin, which is separate from blue and green. This separation ensures that development changes can be made safely and without impacting the live or testing environments, maintaining a clear workflow for updates. The origin environment directly reads the source app model, ensuring a real-time reflection of modifications.[MN1] 

     [MN1]@Johnny Troset Andersen kan denne flyttes til kapittelet over? Fordi det er relatert til blue/ green, ikke Kubernetes (hvis jeg skjønner det riktig?). Eller er det fordi det er Kuberentes at vi kjører Origin?

  • Genus leverages Kubernetes to manage its deployment environments, ensuring scalability, flexibility, and reliability.

    When switching between active and passive environments, Kubernetes updates ingress rules to route traffic to the newly active environment. This process ensures zero downtime for end-users, maintaining a smooth and uninterrupted experience.

    A tool called Genus Operator manages this switching process, automating updates to ingress rules and ensuring that the transition between environments is seamless and reliable.

    Each environment operates independently with a complete set of microservices, enabling:

    • Efficient Scaling: Resources for passive environments can be scaled down to optimize costs.

    • Seamless Session Management: User sessions are preserved during environment switches, ensuring continuity.

    1. Model Changes: A business engineer updates the app model in the origin environment and initiates deployment to the passive environment (e.g., green if blue is active).

    2. Passive Environment Update: The passive environment is updated with the new app model, and services are restarted, making the environment ready for testing.

    3. Testing and Verification: The business engineer and testers validate the update in the passive environment.

    4. Switching Environments: At the scheduled time, the updated environment (green) becomes active, and the previous active environment (blue) becomes passive for potential rollback.

    The Genus platform logs all deployment actions, ensuring transparency and auditability. This process guarantees efficient, reliable updates aligned with enterprise needs.