Deployment Profiles and Capabilities

Deployment profiles decide which features a deployment context can support. This page explains what a profile contains, how availability is computed, and why users never choose a profile. Read it when you add a capability or work on availability.

What a profile is

Some features only work when the environment provides something. Iris needs a Pyris service and a secret. A feature lists these needs in requiresCapabilities, for example iris-service and iris-secret. The extraction pipeline derives the list from the feature's deployment inputs, so the capability ids exist only on the model features.

A deployment profile states which capabilities a deployment context provides. A profile with a providedCapabilities list provides exactly those:

{
  "id": "athena-only-profile",
  "name": "Deployment with Athena as the only external service",
  "providedCapabilities": ["athena-service", "athena-secret"]
}

A profile without the field provides every capability that the active model requires.

A profile declares support only, never values. Service URLs and secrets come from the deployment environment through ${VARIABLE} placeholders in the generated files.

Where profiles come from

The application ships one profile, src/main/resources/deployment-profiles/default-artemis-profile.json. It has no providedCapabilities list, so it provides every capability the active model requires. For local experiments, you can add profiles as JSON files under <data-root>/deployment-profiles/. A local profile with the same id replaces the bundled one. The server reads the profiles on every request, so a changed file takes effect without a restart.

A profile can also list supportedDeploymentModes. Without the field, it supports every deployment mode; with it, generating a package for another mode fails with a controlled error.

Availability

GET /api/feature-model/profile-availability tells the client which options and features are available under the active profile. A feature is available when the active profile provides all its capabilities and when the teacher role may see and configure it. The answer has two levels of detail:

• teacherReason, a readable sentence for the guided workflow. It never shows raw capability ids.
• requiredCapabilities and missingCapabilities, the exact ids for the advanced tree.

An option's availability follows from the capabilities of the features it selects, which the guided workflow derives from the model.

Why the Configurator has no profile selector

Teachers decide about functional features; they should not need to know about service registrations or secrets. The Configurator therefore always uses the default profile, default-artemis-profile, and never asks the user to pick one. Because this profile provides every capability, all features are available in a normal setup.

Availability still matters when a maintainer restricts capabilities with a local profile. The Configurator then leaves features with missing capabilities out of a template's starting selection. When the advanced tree selects such a feature, the Configurator removes it again and shows a note. For tests, the availability endpoint accepts an optional profileId parameter.

Where it lives in the code

Path	Responsibility
deployment/repository/DeploymentProfileRepository	Reads bundled and local profiles
deployment/service/DeploymentProfileService	Lists profiles, resolves a missing capability list from the active model, and picks the default one
deployment/service/CapabilityResolutionService	Computes availability
deployment/domain/DeploymentModes	The ids of the deployment modes
deployment/web/	The profile and availability endpoints

Paths are relative to src/main/java/de/tum/cit/aet/artemis/featuremodel/.