Version control

FL0 has built-in support for version control. You can use this feature to maintain distinct versions of a backend service across multiple environments, safely test features before releasing them to production, and roll-back changes if something goes wrong.

This topic explains how FL0's version control features work.

What is versioned?

In FL0, the following things can be versioned:

  • Flows
  • Database tables
  • Input schemas

The following things cannot be versioned:

  • Auth policies
  • Configuration (e.g. System settings)
  • Installed Marketplace integrations

How versioning works

By default, all projects have a default version. You can find this version — and all other versions — via the project's Version control page. This page is listed in the sidebar.

The default version is called the Release Preview. It contains all of the current working changes to the project, including changes to flows, database tables, and input schemas.

Environments

All versions, including the Release Preview, exist across three environments:

  • Dev
  • UAT
  • Prod

Each environment serves a specific purpose:

  • The Dev environment is for developing features.
  • The UAT environment is for testing features before releasing them.
  • The Prod environment is for releasing features to end-users.

You can see the current environment when the Projects page is open. By default, the Dev environment is selected, as this is where the initial development of features should begin.

Creating new versions

You can create a new version by clicking the Create version button and choosing a name for the version. This creates a snapshot based on the current working changes in the Release Preview.

The project's versions are listed beneath the Release Preview in reverse-chronological order.

Note: You can only create a new version if there are current working changes for the Dev environment. If there aren't, an error will occur.

Deploying versions

Deploying a version makes that version active within its particular environment. For example, if you trigger a flow in the Dev environment, it's the deployed version of that flow that will be triggered.

A project's versions can be independently deployed to each of its environments. If a project has three versions, each version could be deployed to a different environment.

By default, newly created versions are automatically deployed to the Dev environment. This means, immediately after creating a new version, the Dev environment for the Release Preview and for the new version are identical.

Deployments to the UAT and Prod environments must always be done manually.

Warning: If you deploy or re-deploy a version, your current working changes will be lost. Be sure to create a new version (or verify that the changes can be deleted) before deploying versions.

Reverting versions

If you accidentally deploy a version, or if you realize there's an issue with a version, you always have the option of rolling-back the deployment.

Tip: By making effective use of the UAT environment, you can reduce the need to roll-back changes by catching issues before they're released in production.

Current working changes

When you make changes to a project, the starting point for those changes are not necessarily based on the latest version. Instead, the changes are based on the deployed version.

For example, imagine there's four versions of a project:

  • Release Preview
  • Release 3
  • Release 2
  • Release 1

If you deploy Release 2 to the Dev environment, the current working changes visible in the Release Preview will be based on Release 2, even though Release 3 is the later version.

This applies to all environments. For example, if Release 1 is deployed to the UAT environment, the current working changes visible in the Release Preview will be based on Release 1 when the UAT environment is selected.