Version Control Made Simple with Application Frontend Service

[TaliaGurevich]

As developers, we all know that deploying a new version of an application can be both exciting and risky. Whether you’re rolling out a minor UI fix or launching a major redesign, the ability to manage multiple versions with confidence is key to a smooth delivery process.

With Application Frontend Service, version management is built in from the start, letting you deploy, view, roll back, and promote frontend versions directly from the CLI or SAP BTP Cockpit. In this post, we’ll show you how it works and how to make the most of it.

Why Version Management Matters

Application Frontend Service allows you to host and serve UI applications in SAP BTP. But what happens when a bug slips through? Or when you need to test a new version without affecting your end users?

That’s where the versioning concept in Application Frontend Service comes in.

Application Frontend Service supports multiple coexisting versions of the same application, each one deployed independently and maintained separately.
In the manifest.json file of your application, you define the version name using the applicationVersion property. This allows you to deploy multiple versions of the same application, all sharing the same application ID but with different version identifiers.

Every version:

• Has its dedicated version-specific URL
• Can reference different services and codebases
• Can be tested or validated in parallel with the current live version

Each application has exactly one active version at any given time. The active version is served from the application’s main URL. All other versions are accessible only via their version-specific URLs.
The active version is the version that is available to the end users.

When you deploy an application, it becomes the active version by default, served at the application’s main URL. But you can also deploy a version without activating it, test it safely, and switch to it later with a single command.

Real-Life Example: Test and Promote with Zero Downtime

Let’s say you’ve deployed version 0.0.1 of your application, myApp, and it’s running smoothly in production. You’re now working on version 0.0.2 with a few improvements or new features. With Application Frontend Service, you can deploy version 0.0.2 without making it active right away.

Each application in Application Frontend Service is assigned a unique main URL when it is first deployed. For example:

https://myapp-wscfr.eu10.appfront.cloud.sap

This main URL always returns the currently active version of the application.

In addition, each deployed version receives its version-specific URL, such as:

https://myapp-wscfr-v0_0_1.eu10.appfront.cloud.sap
https://myapp-wscfr-v0_0_2.eu10.appfront.cloud.sap

With Application Frontend Service, you can:

• Deploy version 0.0.2 without activating it
• Access it directly through its version-specific URL:
  https://myapp-wscfr-v0_0_2.eu10.appfront.cloud.sap
• Let your testers or internal users try it out
• Keep version 0.0.1 active and served via the main URL
• Once validated, promote version 0.0.2 to active, and your main URL: https://myapp-wscfr.eu10.appfront.cloud.sap will now serve the new version to all users

All of this happens without downtime, without breaking the existing deployment, and without overwriting any previously deployed version.

Controlling Activation During Deployment

In the previous example, we saw how useful it is to deploy a new version without activating it right away.
By default, any new deployment to the Application Frontend Service becomes the active version. But if you want to delay activation, for example, to perform internal validation, you can control this behavior in two ways, depending on how you deploy.

When deploying an application using the GACD (Generic Application Content Deployer) module

If you are deploying a multi-target application (MTA), you can prevent automatic activation by setting activateVersion: false under the parameters of the GACD module in your mta.yaml file:

...
  parameters:
    config:
      activateVersion: false
      destinations:
        - name: ui5
          url: https://ui5.sap.com

When deploying with afctl push

If you're using the Application Frontend service CLI to deploy applications, you can achieve the same behavior using one of the following options:

• Pass the --no-activate (or-n) flag to the afctl push command:

afctl push <path-to-app> -n

• Or set "activateVersion": false in the configuration file (e.g., conf.json):

{
  "activateVersion": false
}

Note: If both the CLI flag and the configuration file contain activation settings, the CLI flag takes precedence.

For example, the following command uses a configuration file that may contain "activateVersion": true, but the -n flag overrides it and prevents activation:

afctl push <path-to-app> -c conf.json -n

With either method, the new version will be deployed and accessible via its version-specific URL. Still, the application’s main URL will continue to serve the currently active version until you explicitly promote the new one.

Managing Application Versions in SAP BTP Cockpit

To access the Application Frontend UI in SAP BTP Cockpit, your user must be assigned the Application Frontend Viewer role. To activate or delete versions, you need the Application Frontend Developer role.

Viewing Your Applications

1. In the left-hand navigation bar of the SAP BTP Cockpit, choose HTML5 / Application Frontend.
2. You'll see a list of applications that have been deployed to the Application Frontend Service in your subaccount.
3. For each application, you can see its active version.
4. To open and run an application, you can click either the application name or the active version.
5. If you choose to delete an application, all of its versions (including the active one) will be permanently deleted.

Viewing and Managing Versions

To see all deployed versions of an application:

1. Click anywhere on the row of the application.
2. A detail pane will open on the right, showing all the deployed versions of that application.

Here you can activate versions, delete them, or view logs for a specific version.

To change the active version of an application:

• Click the Activate version icon on the version you want to promote.
• The active version indicator will move to that version.

Only one version of an application can be active at a time.

To delete a specific version of an application:

• Click the Delete icon on the version you want to remove

Note: This action is permanent. Deleted versions cannot be recovered.

Additional Notes

• You cannot delete an active version. To delete an active version, you must first activate another one.
• An application can have a maximum of 10 versions. Once this limit is reached, you must delete older versions before deploying new ones.

Let’s see how all of this looks in a real example.

I have deployed an application called “employees.” It currently has a single version, 1.0.0, which was activated by default on deployment.

This is how the application looks:

Note the URL. This is the main URL of the application.

I can also run the same version using its version-specific URL:

Now I want to enhance the application by adding search and sort controls, and I also want to remove the “Employees Overview” title.

After making these changes, I deploy version 2.0.0 of the application using the --no-activate flag, meaning this version will not become active immediately.

At this point, two versions of the application exist:

Since the new version was not activated, the main application URL still serves version 1.0.0 - without the new features:

However, I can access and test version 2.0.0 using its version-specific URL:

The search and sort controls are visible, and everything is working as expected.

Next, I activate version 2.0.0.

Now version 2.0.0 is active.

The main application URL serves the updated version with the new features:

The previous version, 1.0.0, remains available through its version-specific URL, and I can roll back to it if needed:

Managing Application Versions with the Application Frontend Service CLI

You can perform the same version management actions using the Application Frontend service CLI.
To activate or delete versions, you need the Application Frontend Developer role.

Activate a version

To activate a specific version of an application, use:

afctl activate APPLICATION VERSION

Arguments:

• APPLICATION – Name of the deployed application
• VERSION – Name of the application version you want to activate

Delete a version

To delete a specific version:

afctl delete APPLICATION VERSION

Caution: If you don't specify an application version, all versions of the application will be deleted. This action cannot be undone.

View all versions
To view versions, your user must be assigned the Application Frontend Viewer role.

To list all deployed versions of an application:

afctl list APPLICATION

For example, if you run afctl list employees after activating version 2.0.0 in the example above, the output would show all available versions, including the active one.

As you can see, with built-in versioning and flexible deployment options, Application Frontend Service makes it easy to deliver updates with confidence.
Whether you work in the SAP BTP Cockpit or prefer the CLI, you can roll out changes safely without impacting the live version during development or testing.