DEV Community: zakaria zermani

Stop Committing Secrets: A Practical Betterleaks + Git Hooks Setup for Every Development Team

zakaria zermani — Thu, 15 Oct 2026 07:38:04 +0000

Security incidents often start with a simple mistake.

A developer accidentally commits an API key, a database password, a private key, or a cloud credential. The secret gets pushed to a repository, appears in CI logs, gets replicated to forks, or becomes part of Git history.

Even when detected quickly, the cleanup can be painful:

Rotate credentials
Clean repository history
Investigate exposure
Update environments
Document the incident

A much better approach is to prevent secrets from being committed in the first place.

In this article, we'll configure Betterleaks and Git pre-commit hooks to automatically scan staged changes and block commits containing sensitive information.

Why Local Secret Scanning Matters

Many organizations rely on:

GitHub Secret Scanning
GitLab Secret Detection
CI/CD security pipelines
Repository scanning solutions

While these tools are important, they usually identify problems after the secret has already entered the repository.

Local scanning shifts detection further left.

Benefits

✅ Immediate feedback for developers

✅ Secrets never reach Git history

✅ Faster remediation

✅ Consistent security practices

✅ Reduced risk of accidental exposure

The earlier a problem is discovered, the cheaper it is to fix.

Step 1: Install Betterleaks

Install Betterleaks on your workstation.

macOS

brew install betterleaks

Linux

BETTERLEAKS_VERSION="1.8.1"

curl -sSfL \
"https://github.com/betterleaks/betterleaks/releases/download/v${BETTERLEAKS_VERSION}/betterleaks_${BETTERLEAKS_VERSION}_linux_x64.tar.gz" \
| tar -xz

sudo mv betterleaks /usr/local/bin/

Verify Installation

betterleaks --version

If a version number is displayed, you're ready to continue.

Step 2: Store Git Hooks Inside the Repository

By default, Git stores hooks inside:

.git/hooks

The problem is that this directory is not version-controlled.

To ensure every developer uses the same hooks, create a dedicated directory:

my-project/
├── .githooks/
│   └── pre-commit
├── .betterleaks.toml
└── README.md

Configure Git to use this directory:

git config core.hooksPath .githooks

This command only needs to be executed once per cloned repository.

Step 3: Create the Pre-Commit Hook

Create the file:

.githooks/pre-commit

Add the following content:

#!/usr/bin/env bash

# Verify Betterleaks is installed
if ! command -v betterleaks &> /dev/null; then
    echo "Betterleaks is not installed."
    echo "Please install Betterleaks before committing."
    exit 1
fi

echo "Running Betterleaks scan..."

betterleaks git . \
    --staged \
    --config .betterleaks.toml

EXIT_CODE=$?

if [ $EXIT_CODE -ne 0 ]; then
    echo ""
    echo "Secrets detected."
    echo "Commit blocked."
    exit 1
fi

echo "No secrets found."
exit 0

Make the hook executable:

chmod +x .githooks/pre-commit

Now every commit will automatically trigger a secret scan.

Step 4: Configure Betterleaks

Create the configuration file:

.betterleaks.toml

Example configuration:

title = "Project-Wide Betterleaks Configuration"

[extend]
useDefault = true

# Optional:
# disabledRules = ["generic-api-key"]

[[rules]]
id = "custom-api-token"

description = "Detect custom API tokens"

regex = '''MYTOKEN_[A-Za-z0-9]{32}'''

keywords = [
  "MYTOKEN_"
]

[allowlist]

description = "Ignore test fixtures"

paths = [
  '''(^|/)testdata/''',
  '''(^|/)fixtures/''',
  '''(^|/)__mocks__/'''
]

stopwords = [
  "dummy_token",
  "example_secret",
  "test_api_key"
]

This configuration:

Uses Betterleaks' built-in detection rules
Adds project-specific secret detection
Reduces false positives
Excludes known test data

Step 5: Test the Setup

Let's verify that the hook works.

Create a file containing a fake GitHub token:

echo "token: ghp_AbC123xYz456D7Ef89GhI01JkLmNoPqRsTuV" > test-secret.txt

Stage the file:

git add test-secret.txt

Attempt a commit:

git commit -m "testing secret detection"

Expected output:

Running Betterleaks scan...

Secrets detected.
Commit blocked.

The commit will fail, preventing the secret from entering the repository.

Handling False Positives

No detection tool is perfect.

If Betterleaks incorrectly identifies a value as a secret, you have several options.

Allow a Specific Line

example_value # betterleaks:allow

Ignore Files or Directories

Create a:

.betterleaksignore

file to define exclusions.

Customize Detection Rules

Adjust your rules inside:

.betterleaks.toml

The goal is to reduce noise while maintaining effective security controls.

Emergency Bypass

In rare situations, you may need to bypass the hook:

git commit --no-verify -m "emergency commit"

Use this carefully.

If developers regularly bypass security controls, it may indicate that the rules need refinement.

Onboarding New Developers

A simple developer onboarding process might look like:

git clone <repository>

cd <repository>

brew install betterleaks

git config core.hooksPath .githooks

That's it.

From that point onward, every commit is automatically checked before it is created.

Defense in Depth: Local + CI/CD Scanning

Local secret scanning should complement, not replace, existing security controls.

A layered approach typically includes:

Layer	Purpose
Pre-Commit Hooks	Immediate developer feedback
Pull Request Validation	Team-level review
CI/CD Scanning	Automated enforcement
Repository Scanning	Continuous monitoring
Secret Management Solutions	Secure storage and rotation

Security controls are most effective when they work together.

Conclusion

Secret leaks are among the easiest security incidents to prevent.

By integrating Betterleaks directly into the local development workflow, teams can catch sensitive information before it enters a repository.

The setup is lightweight, easy to maintain, and provides immediate value without disrupting developers.

If you're already scanning repositories and CI/CD pipelines for secrets, consider adding local detection as another layer of defense.

The best secret leak is the one that never reaches Git in the first place.

Have You Tried Local Secret Scanning?

How does your team prevent accidental secret exposure?

Do you rely on GitHub Secret Scanning, GitLab Secret Detection, gitleaks, Betterleaks, custom tooling, or a combination of approaches?

I'd be interested to hear what has worked best in your environment.

From Ingress API to Gateway API: Why the Migration Is Worth It

zakaria zermani — Sun, 26 Jul 2026 17:29:55 +0000

Kubernetes users have relied on the Ingress API for years as the standard way to route HTTP(S) traffic into a cluster. However, the Ingress API is starting to show its limitations—and that's exactly why the Gateway API has emerged as a more modern and flexible successor.

In this article, we'll explore why migrating makes sense, what changes conceptually, and how common Ingress features map to the Gateway API.

Why Migrate at All?

The Ingress API has three fundamental weaknesses that become apparent very quickly in real-world environments.

1. Limited Functionality

The Ingress API supports only TLS termination and basic content-based routing for HTTP traffic. Need TCP, UDP, or gRPC routing? You're out of luck.

To provide more advanced functionality, Ingress controllers rely heavily on annotations—proprietary extensions that exist outside the actual Kubernetes standard.

The problem is that each implementation (NGINX, Traefik, Envoy, and others) ships with its own set of annotations, which are not necessarily compatible with one another. If you want to switch Ingress controllers, you typically need to:

Identify all annotations currently in use.
Find equivalent functionality in the new controller.
Rebuild the configuration manually.

This makes migrating between implementations difficult—and sometimes nearly impossible.

2. No Real Authorization Model

The classic Ingress model revolves around a single central resource. As a result, there is effectively only one primary role: the person creating the Ingress resource.

That role can simultaneously define routing rules, configure TLS, and in some cases even influence the underlying load-balancing infrastructure.

In small clusters operated by a single team, this isn't usually a problem. But consider the following scenario:

Team A operates an online shop
Team B operates an API
Team C operates a customer portal
All teams share the same load balancer or Ingress controller

The Ingress model provides no clean separation between infrastructure operators, application administrators, and developers. As a result, developers can potentially create configurations that affect shared infrastructure without any standardized role model governing those permissions.

3. An Unwieldy API Design

Annotations are simple key-value strings stored in the metadata section rather than as structured fields within the relevant part of the specification.

As the number of annotations grows, an Ingress resource quickly becomes difficult to read, maintain, and understand.

The Core Differences

Personas

One of the biggest conceptual improvements introduced by the Gateway API is its clearly defined role model.

Ingress API Personas

With the Ingress API, there is essentially only one explicit persona:

User: Owner of the Ingress resources

Additionally, there are two implicit personas:

Infrastructure Provider: Manages a provider-managed Ingress controller
Cluster Operator/Admin: Manages self-hosted Ingress controllers

These personas only became formally recognized with the later introduction of the IngressClass resource.

Gateway API Personas

The Gateway API introduces a clear separation of responsibilities from the start:

Application Developer: Defines routing rules for applications
Application Admin: Defines entry points for external client traffic, including TLS termination
Cluster Operator: Defines gateway entry points and TLS configuration
Infrastructure Provider: Provides the GatewayClass and controller implementation

This model aligns much better with organizations where multiple teams share the same load-balancing infrastructure.

Importantly, adopting the Gateway API does not require abandoning self-service workflows. It remains perfectly possible to define a single RBAC role that combines the responsibilities of Developer, Admin, and Operator.

Functionality and Extensibility

The Gateway API covers all features available in Ingress—and adds many capabilities that previously required annotations. As a result, configurations become significantly more portable across implementations.

For features that cannot realistically be standardized—such as authentication, connection timeouts, or health checks—the Gateway API provides three official extension mechanisms.

External References

A Gateway API resource can reference an implementation-specific custom resource. This keeps the standard API lean while still allowing vendors such as Envoy Gateway or Istio to provide advanced features.

HTTPRoute
   |
   +--> Standard Gateway API fields
   |
   +--> Vendor-specific extension fields (Custom Resource)

For example, an HTTPRouteFilter can use an extensionRef to reference a vendor-specific JWT authentication resource that is not part of the standard:

filters:
- type: ExtensionRef
  extensionRef:
    group: gateway.envoyproxy.io
    kind: JwtAuthentication
    name: company-auth

Custom Implementations

Some features are intentionally left implementation-specific.

A good example is the RegularExpression type of HTTPPathMatch, where behavior depends on the controller implementation. These capabilities fall under the "implementation-specific" or "custom" conformance level.

Policies

For data-plane functionality such as authentication, authorization, rate limiting, WAF rules, or caching, vendors can define their own policy resources.

The Gateway API does not dictate how those resources should be designed, but it does standardize how policies are attached to Gateway API resources. This creates a more consistent user experience across vendors.

The key difference compared to External References is that the policy references the route, not the other way around.

Instead of:

kind: HTTPRoute
spec:
  auth:
    enabled: true

the Gateway API approach looks like this:

kind: HTTPRoute
metadata:
  name: webshop
---
kind: AuthenticationPolicy
spec:
  targetRef:
    kind: HTTPRoute
    name: webshop

Notably, annotations are not considered an official extension mechanism in the Gateway API and are strongly discouraged for implementations.

Feature Mapping: Ingress to Gateway API

Ingress Concept	Gateway API Equivalent
Entry Points	Must be explicitly defined as listeners in a `Gateway` resource
TLS Termination	Defined on the Gateway listener; certificates still reside in Secrets
Routing Rules	Path matching maps directly to an `HTTPRoute`
Default Backend	No direct equivalent; must be defined explicitly as a routing rule using a `/` prefix
IngressClass	`parentRef` in the `HTTPRoute` points to the corresponding `Gateway`

Routing in Detail: Host-Specific vs. Global

A noteworthy difference is how routing rules are associated with hostnames.

With Ingress, each hostname has its own rule block:

spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        backend: shop-service
  - host: api.example.com
    http:
      paths:
      - path: /
        backend: api-service

With HTTPRoute, routing rules automatically apply to all specified hostnames:

spec:
  hostnames:
  - shop.example.com
  - api.example.com
  rules:
  - matches:
      - path:
          value: /
    backendRefs:
      - name: app

Merging and Conflict Resolution

Ingress never standardized how configurations should be merged or how routing conflicts should be resolved. Each controller handles these situations differently.

The Gateway API, in contrast, explicitly defines rule-merging and conflict-resolution behavior, ensuring consistent behavior across conformant implementations.

What About Annotations?

Because annotations are inherently implementation-specific, their migration depends on both the old Ingress controller and the new Gateway implementation.

Let's take NGINX as an example:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

These annotations are understood only by the NGINX Ingress Controller. Other controllers either ignore them or provide their own alternatives.

The good news is that many previously annotation-based features are now part of the official standard.

For example, this:

annotations:
  nginx.ingress.kubernetes.io/ssl-redirect: "true"

becomes a standard Gateway API filter:

filters:
- type: RequestRedirect

For features that remain implementation-specific—such as JWT authentication, WAF rules, or advanced Envoy capabilities—you'll need to consult the documentation of the respective Gateway implementation to identify the appropriate extension mechanism.

Implementations and Conformance

The Gateway API defines two implementation profiles:

Gateway: Designed for north-south traffic
Mesh: Designed for east-west traffic within a cluster or across cluster sets

Each profile has its own conformance tests.

There are currently three conformance levels:

Conformant: e.g., Traefik (Controller), Cilium (Controller & Mesh)
Partially Conformant: e.g., Envoy Gateway (used, among others, by Giant Swarm)
Stale: e.g., Azure Application Gateway for Containers (Controller)

Automated Migration

Fortunately, migrating doesn't have to start from scratch.

The Kubernetes SIGs project ingress2gateway automatically converts existing Ingress resources into Gateway API resources and can significantly reduce the amount of manual work involved:

https://github.com/kubernetes-sigs/ingress2gateway

Conclusion

The Gateway API addresses the three biggest shortcomings of the Ingress API at once: richer built-in functionality, a clear role model for multi-team Kubernetes environments, and a structured API design that replaces annotation sprawl with well-defined resources and extension mechanisms.

If you're currently struggling with large numbers of implementation-specific annotations or coordinating multiple teams on shared Ingress infrastructure, it's well worth taking a serious look at migrating to the Gateway API—ideally with ingress2gateway as a starting point for the transition.

Entwicklung auf SAP BTP: Struktur, Tools & Deployment im Überblick

zakaria zermani — Sun, 04 May 2025 20:24:27 +0000

Einführung in SAP BTP

Was ist SAP Business Technology Platform?

Die SAP Business Technology Platform (SAP BTP) ist eine integrierte Plattform-as-a-Service (PaaS), die es Unternehmen ermöglicht, Anwendungen und Erweiterungen effizient zu entwickeln, zu integrieren und bereitzustellen. SAP BTP kombiniert Datenbankdienste, Analytik, Integrationsfunktionen sowie Anwendungsentwicklungstools in einer zentralen Umgebung. Sie unterstützt verschiedene Laufzeitumgebungen, darunter Cloud Foundry, Kyma und ABAP.

Warum auf SAP BTP entwickeln?

Die Entwicklung auf SAP BTP bietet zahlreiche Vorteile: Entwickler:innen können Anwendungen schnell in der Cloud erstellen, bestehende SAP-Lösungen erweitern und gleichzeitig moderne Technologien wie Machine Learning oder Event-driven Architecture nutzen. Durch die nahtlose Integration mit SAP S/4HANA, SAP SuccessFactors und anderen Systemen wird die BTP zur idealen Plattform für unternehmensweite Innovationen.

Die SAP BTP Account-Struktur verstehen

Global Account, Subaccount & Directories

Die Account-Struktur von SAP BTP ist hierarchisch aufgebaut. An oberster Stelle steht der Global Account, dem Subaccounts untergeordnet sind. Innerhalb des global accounts oder der Subaccounts können sogenannte Directories erstellt werden, um eine strukturierte Organisation zu ermöglichen – etwa nach Teams, Projekten oder Regionen.

Cloud Foundry Subaccount: Aufbau und Organisation

Ein Subaccount in der Cloud Foundry (CF) Umgebung entspricht einer eigenen Entwicklungs- und Laufzeitumgebung. Innerhalb eines CF-Subaccounts wird automatisch eine Organisation (Org) erstellt, zu der mehrere Spaces gehören können. Diese Spaces ermöglichen die Aufteilung von Ressourcen, Rollen und Deployments, z. B. für Entwicklung, Test und Produktion.

Orgs und Spaces: Hierarchie und Struktur

In der CF-Umgebung gilt eine 1:1-Beziehung zwischen Subaccount und Org. Eine Org kann jedoch beliebig viele Spaces beinhalten. Diese Trennung erlaubt eine granulare Zuweisung von Ressourcen (z. B. Quota, Memory) und fördert die Kollaboration in Projektteams. Spaces sind also essenziell für eine strukturierte und skalierbare Entwicklungslandschaft auf BTP.

Beispielhafte Struktur: Eine Skizze zur Visualisierung

Visuelle Darstellung der Account-Hierarchie

Zur besseren Verständlichkeit bietet sich eine grafische Skizze an, die die Hierarchie von Global Account → Subaccount → Directory → Org → Space darstellt. Diese Struktur bildet das Fundament für die technische Umsetzung von Berechtigungen, Ressourcenmanagement und Anwendungsbereitstellung auf SAP BTP.

Quelle: https://developers.sap.com/tutorials/cp-trial-quick-onboarding.html

Empfohlene Aufteilung nach Use Case

Ein bewährtes Modell ist die Aufteilung der Subaccounts nach Region oder Business Unit, kombiniert mit einer projektbezogenen Nutzung der Directories und Spaces. So lassen sich verschiedene Anwendungsfälle – von ABAP-Entwicklung bis zu UI5-Webapps – klar trennen und effizient verwalten.

Entitlements vs. Quotas

Was sind Entitlements?

In SAP BTP bezeichnen Entitlements die Zuweisung von Diensten und Ressourcen an Subaccounts. Sie legen fest, welche Services überhaupt genutzt werden dürfen – zum Beispiel SAP HANA Cloud, Business Application Studio oder die ABAP Environment. Diese Berechtigungen werden auf der Ebene des Global Accounts verwaltet.

Quota Management im globalen Account

Quotas bestimmen, in welchem Umfang ein Dienst innerhalb eines Subaccounts verwendet werden darf. Während ein Entitlement lediglich die grundsätzliche Nutzung erlaubt, limitiert die Quota die konkrete Ressourcennutzung (z. B. Anzahl der Serviceinstanzen oder Speichermenge). Ein gutes Quota-Management ist entscheidend, um Performance und Kosten im Griff zu behalten.

Regionale Bindung eines Subaccounts

Jeder Subaccount ist genau einer Region zugeordnet. Diese Region beeinflusst unter anderem die Verfügbarkeit von Diensten, Latenzzeiten und die rechtliche Rahmenbedingungen bezüglich Datenhaltung. Daher ist es sinnvoll, Subaccounts strategisch nach geografischer Nähe zu Nutzern oder regulatorischen Anforderungen auszuwählen.

Tools für Entwickler:innen auf SAP BTP

Was ist die BTP CLI?

Die BTP Command Line Interface (BTP CLI) ist ein zentrales Tool zur Verwaltung von globalen Accounts, Subaccounts, Directories und Diensten. Im Gegensatz zur CF CLI, die ausschließlich für die Cloud Foundry Umgebung zuständig ist, adressiert die BTP CLI die gesamte Plattformstruktur und erlaubt unter anderem die Aktivierung von Diensten, Zuweisung von Entitlements und das Konfigurieren von Directories.

Unterschiede zur CF CLI

Die CF CLI ist spezialisiert auf die Interaktion mit der Cloud Foundry Umgebung – also auf das Deployment, die Verwaltung von Apps, Services, Orgs und Spaces. Die BTP CLI hingegen deckt übergeordnete Plattformebenen ab, wie die Einrichtung von Subaccounts, Service-Plänen und globalen Rollen. Für ein vollständiges Management der BTP-Struktur ist die Nutzung beider CLIs oft notwendig.

BTP CLI: Kontextbasiertes Arbeiten (global, subaccount, directory)

Ein zentraler Aspekt der BTP CLI ist das Arbeiten im kontextbasierten Modus. Dabei kann ein spezifischer Kontext (z. B. ein bestimmter Subaccount oder ein Directory) als Ziel gesetzt werden. Wenn Sie also den Kontext, in dem Befehle ausgeführt werden, auf ein Directory oder ein Subaccount ändern wollen, können Sie dies mit dem Befehl **btp target** tun.

Arbeiten mit dem SAP Business Application Studio

Dev Spaces erstellen und nutzen

Das SAP Business Application Studio (BAS) ist eine moderne, webbasierte Entwicklungsumgebung auf der SAP BTP. Entwickler:innen können darin sogenannte Dev Spaces erstellen – vorinstallierte, isolierte Entwicklungsumgebungen, die sofort einsatzbereit sind. Je nach gewähltem Szenario (z. B. SAP Fiori, CAP, ABAP) sind die entsprechenden Tools, Extensions und Laufzeitumgebungen bereits integriert.

Voraussetzungen und Subscription

Um mit dem BAS arbeiten zu können, muss der Dienst zunächst über den Subaccount abonniert werden. Dies setzt voraus, dass im Global Account entsprechende Entitlements vergeben wurden. Die Nutzung ist sowohl im kostenlosen Trial als auch im Enterprise Account möglich. Nach der Aktivierung kann direkt mit der Erstellung und Verwaltung von Dev Spaces begonnen werden.

Entwicklungsumgebungen nach Szenarien

Jede Dev Space Type ist auf ein bestimmtes Anwendungsszenario optimiert. Zum Beispiel beinhaltet ein „SAP Fiori“-Space UI5-Toolkit, OData-Editoren und Deployment-Tools, während ein „CAP“-Space Node.js-basierte CAP-Runtime, SQLite und CDS-Kommandos enthält. Diese maßgeschneiderte Bereitstellung spart Zeit, reduziert manuelle Konfiguration und verbessert die Produktivität erheblich.

Deployment in der Cloud Foundry Umgebung

Was ist das Manifest.yml?

Beim Deployment von Anwendungen in der Cloud Foundry Umgebung spielt die Datei manifest.yml eine zentrale Rolle. Sie beschreibt die App-Konfiguration, darunter Name, Speicherbedarf, Instanzanzahl, Buildpack, Hostname und Services. Das Manifest automatisiert und standardisiert den Deployment-Prozess, wodurch Fehlerquellen minimiert werden.

App-URL und Hostname-Regeln im SAP BTP Umfeld

Der Hostname einer App muss innerhalb einer Region eindeutig sein. Eine beispielhafte URL für eine App mit dem Hostnamen myapp in der Region EU10 lautet: myapp.cfapps.eu10.hana.ondemand.com. Entwickler:innen sollten bei der Namensgebung daher auf Kollisionen achten oder alternativ mit zufälligen Routen arbeiten.

Automatisch generierte Routen mit random-route

Ein praktisches Attribut in der manifest.yml ist die random-route: true, um eine eindeutige Routen-URL generieren zu lassen. Dadurch wird der App-Hostname automatisch um eine zufällige Zeichenfolge erweitert, was die eindeutige Adressierung vereinfacht. Diese Option ist besonders nützlich in Test- und Entwicklungsszenarien, in denen die exakte URL zweitrangig ist.

Routing zur Dev Space und Mapping zur App

Für den externen Zugriff auf die Anwendung muss eine Route zur entsprechenden Dev Space eingerichtet und mit der App verknüpft werden. Dies erfolgt in der Regel automatisch beim Deployment, kann aber auch manuell angepasst werden. Eine korrekt konfigurierte Route stellt sicher, dass Benutzer:innen und externe Systeme zuverlässig auf die Anwendung zugreifen können.

Fazit: Effiziente Entwicklung auf SAP BTP

Zusammenfassung der wichtigsten Punkte

SAP BTP bietet eine leistungsstarke und flexible Plattform für die moderne Anwendungsentwicklung in der Cloud. Durch die klare Account-Hierarchie – von Global Account über Subaccount bis zu Spaces – wird eine strukturierte Ressourcennutzung ermöglicht. Mit Tools wie der BTP CLI und dem SAP Business Application Studio lassen sich Entwicklungsprojekte effizient umsetzen, erweitern und verwalten.

Besonderes Augenmerk sollte auf die korrekte Konfiguration von Entitlements, Quotas und Deployment-Prozessen gelegt werden. Gerade für ABAP-Entwickler:innen eröffnet SAP BTP mit der Steampunk-Umgebung neue Perspektiven für zukunftssichere Cloud-Lösungen.

Best Practices für den Einstieg

Plane die Account-Struktur frühzeitig und regionsbezogen
Nutze Dev Spaces passend zum jeweiligen Anwendungsszenario
Verwalte Entitlements zentral über den Global Account

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen einem Subaccount und einer Org in SAP BTP?

Ein Subaccount ist Teil der globalen Accountstruktur von SAP BTP und stellt eine Umgebung für Projekte bereit. Innerhalb eines Subaccounts wird automatisch eine Organisation (Org) für die Cloud Foundry Umgebung erstellt, die wiederum in Spaces unterteilt werden kann.

Wie kann ich ABAP-Anwendungen auf SAP BTP entwickeln?

Dazu wird ein Subaccount mit Cloud Foundry Umgebung benötigt, in dem ein Space für die ABAP Environment angelegt wird. Über das SAP Business Application Studio oder Eclipse ADT können Anwendungen mit dem RAP-Modell entwickelt und bereitgestellt werden.

Welche Vorteile bietet die Nutzung von Dev Spaces im Business Application Studio?

Dev Spaces sind sofort einsatzbereite, isolierte Entwicklungsumgebungen in der Cloud, die alle nötigen Tools für spezifische Szenarien enthalten – z. B. Fiori, CAP oder ABAP. Das spart Konfigurationszeit und verbessert die Produktivität.

Wie funktioniert das Deployment einer App in SAP BTP Cloud Foundry?

Das Deployment erfolgt meist über ein manifest.yml, das die Konfiguration der App beschreibt. Mittels CF CLI kann die App dann in einem bestimmten Space deployed und mit Services wie Logging oder Datenbanken verbunden werden.

Was sind Entitlements und warum sind sie wichtig?

Entitlements sind Dienst-Berechtigungen, die im Global Account verwaltet und an Subaccounts vergeben werden. Ohne Entitlement kann ein Dienst nicht aktiviert oder genutzt werden – sie sind also essenziell für die Ressourcenplanung.