1. Latest Release Home
  2. Guides
  3. Concepts
  4. Tools
  5. References
  6. Integrations
  7. Data Apps (Blueprints)
  8. Data Governance
  9. Incorta Applications
    1. Build applications via the Builder Agent
    2. Publish an application
    3. Manage application databases
    4. Manage application secrets
    5. Manage application versions
    6. AppKit CLI
  10. Release Notes
  11. Incorta Premium
  12. Release Support Policy
  13. Release Model

Guides → Manage Application Versions

Context

This content applies to Incorta Cloud deployments only.

Every change to an application creates a new version. You can view the version history, preview any version, revert to an earlier version, and choose which version to publish. This guide explains how versions, previews, and the dev server relate to each other, and how to work with them in the Incorta UI.

Versions, previews, and the dev server

Versions

A version is a snapshot of the whole application. Incorta creates a version every time the Builder Agent finishes a change, and every time you push changes with the AppKit CLI.

  • Versions are numbered oldest-first. Version 3 stays version 3 as newer versions are added.
  • Versions are never overwritten or deleted. Every version stays available.
  • The current version is the version you are working on. After you publish, the live version is the version your users see. The current version and the live version are often the same, but not always.

Previews

A preview is a built copy of one specific version, served at its own address. Use a preview to view or share a version other than the one you are working on.

  • Incorta builds a preview automatically after each version is created.
  • Each preview has its own address, tied to its version.
  • Previews are kept indefinitely, so the preview of an earlier version stays available.
  • Users must sign in with their Incorta account to open a preview, the same as for a published application.
Note

Preview addresses are for review during development. To share an application with its users, publish it.

The dev server

The dev server is the application running live while you build it. Unlike a preview, the dev server is not a built snapshot. It runs your latest changes.

  • The dev server starts when you need it and stops automatically after a period of inactivity.
  • The dev server has its own address, separate from any preview.
  • Stopping the dev server does not lose any work. Your work is saved in the application's workspace, not in the running server.
  • Starting the dev server takes a moment to install the application's dependencies.

Comparison

Dev serverPreviewPublished application
ShowsThe live application with your latest changesOne specific built versionThe version you published
AddressOne per applicationOne per versionA stable address that you choose
LifetimeStops when idleKept indefinitelyUntil you unpublish

The workspace

Each application has a workspace: a Git repository that holds the application's files and full history. The Builder Agent edits the workspace, the AppKit CLI clones it, and each version is a commit in it.

You do not need to work with the workspace in the UI. If you use the AppKit CLI, you work with the workspace as a standard Git repository. For details, refer to References → AppKit CLI?.

Steps to view the version history

  1. Open the application.
  2. In the Application Editor, select the Version history icon (clock).

The Version history list shows every version, newest first, with the time each version was created. The version you are working on is labeled Current.

To open the chat message that created a version, select the Go to message icon (speech bubble) next to the version.

Note

In the chat, each change the Builder Agent makes appears as a card with the version number, a summary of the changes, and Details and Preview buttons. The newest version is labeled Latest.

Steps to preview a version

  1. In the chat, find the card of the version you want to view.
  2. Select Preview.

If the preview of the current version fails to build, you can retry the build from the version history. You can retry only the preview of the current version.

Steps to revert to an earlier version

Reverting restores the workspace to the contents of an earlier version. The version history is preserved: reverting does not delete the versions created after the one you revert to, but the work in those versions is no longer active. Reverting does not create a new version. It moves the “Published” tag back to the earlier version and marks the later ones as reverted. Reverted versions can be restored.

Warning: Development data loss

Reverting syncs the development database to the schema of the version you revert to. Tables and columns added in later versions are dropped, and their development data may be lost. Reverting does not affect the production database.

  1. In the Application Editor, select the Version history icon.
  2. Next to the version you want to restore, select the Revert to this version icon.
  3. In the Revert to this version? dialog, review the changes, and then confirm the revert.
Note

You cannot revert while the Builder Agent is working. Wait for the agent to finish.

Steps to publish a version

The Production page shows the live version and the next version that is ready to publish.

  1. Select More, and then select Production.
  2. Review the version status:
    • Live: The version that is published, with its address and the user who published it.
    • Next up: The newest version, labeled Ready to publish, when it is newer than the live version. When the live version is the newest, this area shows Latest version with the label Up to date.
  3. Select one of the following:
    • Publish vN: Publishes the newest version. The live version stays live until the new version passes every publish step.
    • Republish vN: Publishes the live version again. Use this option to retry a failed publish step from a clean state.

A publish runs the following steps: build, security check, production database, plan database changes, expand database schema, go live, and apply destructive database changes. Steps that have no work to do are skipped. To view the details and duration of each step in the most recent publish, in the Last publish section, select Show steps.

The History section lists every publish run, newest first, with the version, start time, user, address, and duration. To view the steps of a run, expand the run.

For details about publishing and the security check, refer to Guides → Publish an Application.

Steps to view the logs of a version

  1. Select More, and then select Logs.
  2. In the source list, select Dev-server or a specific version.
  3. Optionally, enter text in the search box or filter the logs by level.