Transport Management auf SAP BTP

kategorie

DevOps

Veröffentlicht

Feb 14, 2026

autor

Transport Management auf SAP BTP unterscheidet sich fundamental vom klassischen On-Premise-Ansatz. Statt Transportauftraegen und Transport Management System (TMS) kommt ein Git-basierter Workflow zum Einsatz, der moderne DevOps-Praktiken ermoeglicht.

Transport-Konzepte auf BTP

Auf SAP BTP ABAP Environment gibt es keine klassischen Transportauftraege mehr. Stattdessen basiert das Transport-Management auf Software Components und Git-Repositories:

Konzept	Klassisch (On-Premise)	SAP BTP
Transport-Einheit	Transportauftrag	Git-Commit
Transport-Schicht	TMS-Konfiguration	Git-Branches
Transport-Tool	STMS	Manage Software Components
Workflow	Transport freigeben	Push/Pull via Git
Versionierung	Transportlogs	Git-Historie
Rollback	Manueller Import	Git Revert/Checkout

Architektur-Uebersicht

┌─────────────────────────────────────────────────────────────────────────────┐
│                    SAP BTP Transport-Architektur                             │
│                                                                              │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐                  │
│  │     DEV      │    │     QAS      │    │     PRD      │                  │
│  │   System     │    │   System     │    │   System     │                  │
│  │              │    │              │    │              │                  │
│  │ ┌──────────┐ │    │ ┌──────────┐ │    │ ┌──────────┐ │                  │
│  │ │ Software │ │    │ │ Software │ │    │ │ Software │ │                  │
│  │ │ Component│ │    │ │ Component│ │    │ │ Component│ │                  │
│  │ └────┬─────┘ │    │ └────┬─────┘ │    │ └────┬─────┘ │                  │
│  └──────│───────┘    └──────│───────┘    └──────│───────┘                  │
│         │                   │                   │                           │
│         │ Push              │ Pull              │ Pull                      │
│         ▼                   ▼                   ▼                           │
│  ┌────────────────────────────────────────────────────────────────┐        │
│  │                      Git Repository                             │        │
│  │                                                                  │        │
│  │   main ─────────────────────────────────────────────────────    │        │
│  │         │                    │                                   │        │
│  │   develop ───────────────────┴───────────────────────────       │        │
│  │            │                                                     │        │
│  │   feature/new-api ───────────┘                                  │        │
│  │                                                                  │        │
│  └────────────────────────────────────────────────────────────────┘        │
└─────────────────────────────────────────────────────────────────────────────┘

gCTS vs. klassisches CTS

Gegenueberstellung

Feature	Klassisches CTS	gCTS (Git-enabled CTS)
Versionskontrolle	SAP-proprietaer	Standard Git
Branching	Nicht moeglich	Vollstaendiges Branching
Merge/Diff	Eingeschraenkt	Standard Git-Tools
Code Review	Nicht integriert	Pull Requests
CI/CD	Aufwaendig	Native Integration
Rollback	Manuell, komplex	Git Revert/Reset
Parallelentwicklung	Konflikttraechtig	Feature Branches
Audit Trail	Transportlogs	Git-Historie

Wann welches System?

gCTS: Standard auf SAP BTP, empfohlen fuer alle Neuprojekte
Klassisches CTS: Nur noch fuer On-Premise-Systeme ohne Git-Integration

Landscape Management

Typische Systemlandschaft

Eine professionelle SAP BTP-Landschaft besteht aus mehreren ABAP Environments:

┌─────────────────────────────────────────────────────────────────────────────┐
│                        SAP BTP Subaccount                                    │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐ │
│  │ Space: Development                                                      │ │
│  │                                                                         │ │
│  │  ┌───────────────────────────────────────────────────────────────────┐ │ │
│  │  │ ABAP Environment Instance: DEV                                     │ │ │
│  │  │ - Freie Entwicklung                                                │ │ │
│  │  │ - Lokale Tests                                                     │ │ │
│  │  │ - Feature Branches                                                 │ │ │
│  │  │ - Branch: develop, feature/*                                       │ │ │
│  │  └───────────────────────────────────────────────────────────────────┘ │ │
│  └────────────────────────────────────────────────────────────────────────┘ │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐ │
│  │ Space: Quality                                                          │ │
│  │                                                                         │ │
│  │  ┌───────────────────────────────────────────────────────────────────┐ │ │
│  │  │ ABAP Environment Instance: QAS                                     │ │ │
│  │  │ - Integrationstests                                                │ │ │
│  │  │ - Abnahmetests                                                     │ │ │
│  │  │ - Release-Vorbereitung                                             │ │ │
│  │  │ - Branch: main (Release Candidates)                                │ │ │
│  │  └───────────────────────────────────────────────────────────────────┘ │ │
│  └────────────────────────────────────────────────────────────────────────┘ │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐ │
│  │ Space: Production                                                       │ │
│  │                                                                         │ │
│  │  ┌───────────────────────────────────────────────────────────────────┐ │ │
│  │  │ ABAP Environment Instance: PRD                                     │ │ │
│  │  │ - Produktiver Betrieb                                              │ │ │
│  │  │ - Nur getesteter Code                                              │ │ │
│  │  │ - Branch: main (nur Tags)                                          │ │ │
│  │  └───────────────────────────────────────────────────────────────────┘ │ │
│  └────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

Branch-Strategie pro System

System	Branch	Zweck	Update-Frequenz
DEV	develop, feature/*	Aktive Entwicklung	Kontinuierlich
QAS	main	Integrationstests	Nach Merge
PRD	main (Tags)	Produktiv	Release-basiert

Transport-Workflow auf BTP

Schritt 1: Entwicklung im DEV-System

" Entwickler arbeitet auf einem Feature-Branch
" 1. Branch auschecken (via Manage Software Components App)
" 2. Code entwickeln und testen
" 3. Aenderungen committen

" Commit-Message Konvention:
" feat: Neue Berechtigungspruefung hinzugefuegt
" fix: Berechnungsfehler in Preiskalkulation behoben
" refactor: Customer-Service-Klasse umstrukturiert

Schritt 2: Pull Request erstellen

Nach Abschluss der Entwicklung wird ein Pull Request im Git-Repository erstellt:

┌────────────────────────────────────────────────────────────────────────────┐
│  Pull Request: feature/order-validation → main                              │
│                                                                             │
│  Title: feat: Add order validation before submission                       │
│                                                                             │
│  Description:                                                               │
│  - Validates order quantities against stock                                 │
│  - Checks customer credit limit                                             │
│  - Sends notification on validation failure                                 │
│                                                                             │
│  Changes: 5 files changed, +234 -12                                        │
│                                                                             │
│  Checks:                                                                    │
│  ✓ ABAP Unit Tests passed (42/42)                                          │
│  ✓ ATC Check passed (0 errors, 3 warnings)                                 │
│  ✓ Code Coverage: 87%                                                      │
│                                                                             │
│  Reviewers:                                                                 │
│  ☑ @senior-developer (approved)                                            │
│  ☐ @tech-lead (pending)                                                    │
│                                                                             │
│  [Merge Pull Request]  [Close]                                              │
└────────────────────────────────────────────────────────────────────────────┘

Schritt 3: Import ins QAS-System

┌────────────────────────────────────────────────────────────────────────────┐
│  Manage Software Components - QAS System                                    │
│                                                                             │
│  Component: ZCUSTOM_ORDER                                                  │
│  Current Branch: main                                                       │
│  Current Commit: abc123f "feat: Add order validation..."                   │
│                                                                             │
│  Remote Status:                                                             │
│  ⚠ 2 commits behind remote                                                  │
│                                                                             │
│  New Commits:                                                               │
│  - def456g: feat: Add order validation before submission                   │
│  - 789hij0: fix: Correct currency conversion                               │
│                                                                             │
│  [Pull]  [Checkout Branch]  [History]                                       │
└────────────────────────────────────────────────────────────────────────────┘

Schritt 4: Release und PRD-Deployment

" Release-Prozess:
" 1. QAS-Tests erfolgreich abgeschlossen
" 2. Release-Tag im Git-Repository erstellen (z.B. v1.2.0)
" 3. Tag in PRD-System auschecken

" Git-Tag erstellen (ueber GitHub/GitLab UI oder CLI):
" git tag -a v1.2.0 -m "Release 1.2.0 - Order Validation"
" git push origin v1.2.0

Praktisches Beispiel: Feature-Transport

Ausgangssituation

Ein neues Feature “Kundenkreditlimit-Pruefung” soll entwickelt und transportiert werden.

1. Feature-Branch erstellen und entwickeln

" Im DEV-System:
" 1. Manage Software Components App oeffnen
" 2. Component ZCUSTOM_ORDER auswaehlen
" 3. "Checkout Branch" > "Create New Branch"
" 4. Branch-Name: feature/credit-limit-check

CLASS zcl_credit_limit_validator DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_validation_result,
        is_valid     TYPE abap_bool,
        message      TYPE string,
        credit_limit TYPE wertv8,
        credit_used  TYPE wertv8,
      END OF ty_validation_result.

    METHODS:
      validate_order
        IMPORTING iv_customer_id TYPE kunnr
                  iv_order_value TYPE wertv8
        RETURNING VALUE(rs_result) TYPE ty_validation_result.

ENDCLASS.

CLASS zcl_credit_limit_validator IMPLEMENTATION.

  METHOD validate_order.
    " Kundenkreditlimit aus CDS View lesen
    SELECT SINGLE
      credit_limit,
      credit_used
    FROM zi_customer_credit
    WHERE customer_id = @iv_customer_id
    INTO (@rs_result-credit_limit, @rs_result-credit_used).

    IF sy-subrc <> 0.
      rs_result-is_valid = abap_false.
      rs_result-message = |Kunde { iv_customer_id } nicht gefunden|.
      RETURN.
    ENDIF.

    " Verfuegbares Kreditlimit pruefen
    DATA(lv_available) = rs_result-credit_limit - rs_result-credit_used.

    IF iv_order_value <= lv_available.
      rs_result-is_valid = abap_true.
      rs_result-message = |Kreditlimit OK. Verfuegbar: { lv_available }|.
    ELSE.
      rs_result-is_valid = abap_false.
      rs_result-message = |Kreditlimit ueberschritten. Verfuegbar: { lv_available }, Benoetigt: { iv_order_value }|.
    ENDIF.
  ENDMETHOD.

ENDCLASS.

2. Unit Tests schreiben

CLASS zcl_credit_limit_validator_test DEFINITION
  FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT.

  PRIVATE SECTION.
    CLASS-DATA:
      mo_environment TYPE REF TO if_cds_test_environment.

    CLASS-METHODS:
      class_setup,
      class_teardown.

    METHODS:
      setup,
      test_valid_credit_limit FOR TESTING,
      test_exceeded_credit_limit FOR TESTING,
      test_customer_not_found FOR TESTING.
ENDCLASS.

CLASS zcl_credit_limit_validator_test IMPLEMENTATION.

  METHOD class_setup.
    mo_environment = cl_cds_test_environment=>create_for_multiple_cds(
      VALUE #( ( i_for_entity = 'ZI_CUSTOMER_CREDIT' ) )
    ).
  ENDMETHOD.

  METHOD class_teardown.
    mo_environment->destroy( ).
  ENDMETHOD.

  METHOD setup.
    mo_environment->clear_doubles( ).

    " Testdaten einfuegen
    DATA(lt_credits) = VALUE zt_customer_credit_t(
      ( customer_id = '1000' credit_limit = 50000 credit_used = 20000 )
      ( customer_id = '2000' credit_limit = 10000 credit_used = 9500 )
    ).
    mo_environment->insert_test_data( lt_credits ).
  ENDMETHOD.

  METHOD test_valid_credit_limit.
    " Given
    DATA(lo_cut) = NEW zcl_credit_limit_validator( ).

    " When - Bestellung unter verfuegbarem Limit
    DATA(ls_result) = lo_cut->validate_order(
      iv_customer_id = '1000'
      iv_order_value = 25000 " 30000 verfuegbar
    ).

    " Then
    cl_abap_unit_assert=>assert_true( ls_result-is_valid ).
  ENDMETHOD.

  METHOD test_exceeded_credit_limit.
    " Given
    DATA(lo_cut) = NEW zcl_credit_limit_validator( ).

    " When - Bestellung ueber verfuegbarem Limit
    DATA(ls_result) = lo_cut->validate_order(
      iv_customer_id = '2000'
      iv_order_value = 1000 " Nur 500 verfuegbar
    ).

    " Then
    cl_abap_unit_assert=>assert_false( ls_result-is_valid ).
    cl_abap_unit_assert=>assert_char_cp(
      act = ls_result-message
      exp = '*ueberschritten*'
    ).
  ENDMETHOD.

  METHOD test_customer_not_found.
    " Given
    DATA(lo_cut) = NEW zcl_credit_limit_validator( ).

    " When - Unbekannter Kunde
    DATA(ls_result) = lo_cut->validate_order(
      iv_customer_id = '9999'
      iv_order_value = 1000
    ).

    " Then
    cl_abap_unit_assert=>assert_false( ls_result-is_valid ).
    cl_abap_unit_assert=>assert_char_cp(
      act = ls_result-message
      exp = '*nicht gefunden*'
    ).
  ENDMETHOD.

ENDCLASS.

3. Commit und Push

Nach erfolgreichen lokalen Tests:

┌────────────────────────────────────────────────────────────────────────────┐
│  Commit Changes                                                             │
│                                                                             │
│  Branch: feature/credit-limit-check                                        │
│                                                                             │
│  Changed Objects:                                                           │
│  ☑ ZCL_CREDIT_LIMIT_VALIDATOR     (Class)                                  │
│  ☑ ZCL_CREDIT_LIMIT_VALIDATOR_TEST (Test Class)                            │
│  ☑ ZI_CUSTOMER_CREDIT             (CDS View)                               │
│                                                                             │
│  Commit Message:                                                            │
│  ┌────────────────────────────────────────────────────────────────────────┐│
│  │ feat: Add credit limit validation for customer orders                  ││
│  │                                                                        ││
│  │ - Check available credit before order submission                       ││
│  │ - Return detailed validation result with messages                      ││
│  │ - Add unit tests with 100% coverage                                    ││
│  └────────────────────────────────────────────────────────────────────────┘│
│                                                                             │
│  [Commit]  [Commit & Push]  [Cancel]                                        │
└────────────────────────────────────────────────────────────────────────────┘

4. Pull Request und Merge

Nach erfolgreichem Code Review wird der Pull Request gemergt:

# Im Git-Repository (GitHub/GitLab):
# 1. Pull Request: feature/credit-limit-check → main
# 2. CI/CD Pipeline laeuft automatisch
# 3. Nach Approval: Merge durchfuehren

5. QAS-Import

┌────────────────────────────────────────────────────────────────────────────┐
│  Manage Software Components - QAS                                           │
│                                                                             │
│  Action: Pull latest changes                                                │
│                                                                             │
│  ┌────────────────────────────────────────────────────────────────────────┐│
│  │ Pull Progress                                                          ││
│  │ ████████████████████████████████████████████████████████░░░░ 92%      ││
│  │                                                                        ││
│  │ - Fetching remote changes...           ✓                              ││
│  │ - Downloading objects...               ✓                              ││
│  │ - Importing ABAP objects...            ✓                              ││
│  │ - Activating objects...                ⟳                              ││
│  │ - Running post-import checks...        ○                              ││
│  └────────────────────────────────────────────────────────────────────────┘│
│                                                                             │
│  Objects to import: 3                                                       │
│  - ZCL_CREDIT_LIMIT_VALIDATOR                                              │
│  - ZCL_CREDIT_LIMIT_VALIDATOR_TEST                                         │
│  - ZI_CUSTOMER_CREDIT                                                      │
│                                                                             │
└────────────────────────────────────────────────────────────────────────────┘

CI/CD Integration

GitHub Actions Pipeline

name: ABAP Transport Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

env:
  ABAP_PACKAGE: ZCUSTOM_ORDER

jobs:
  # Stage 1: Build und Tests
  test:
    name: ABAP Unit Tests & ATC
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Run ABAP Unit Tests
        uses: SAP/abap-ci-action@v1
        with:
          abap-endpoint: ${{ secrets.DEV_ENDPOINT }}
          username: ${{ secrets.ABAP_USER }}
          password: ${{ secrets.ABAP_PASSWORD }}
          package: ${{ env.ABAP_PACKAGE }}

      - name: Run ATC Checks
        uses: SAP/abap-atc-action@v1
        with:
          abap-endpoint: ${{ secrets.DEV_ENDPOINT }}
          username: ${{ secrets.ABAP_USER }}
          password: ${{ secrets.ABAP_PASSWORD }}
          package: ${{ env.ABAP_PACKAGE }}
          variant: Z_CI_CHECKS

  # Stage 2: Deploy to QAS
  deploy-qas:
    name: Deploy to QAS
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: quality-assurance

    steps:
      - name: Pull to QAS System
        run: |
          curl -X POST \
            "${{ secrets.QAS_ENDPOINT }}/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER/pull" \
            -u "${{ secrets.DEPLOY_USER }}:${{ secrets.DEPLOY_PASSWORD }}" \
            -H "Content-Type: application/json" \
            -d '{"branch": "main"}'

      - name: Verify Deployment
        run: |
          # Warten auf Aktivierung
          sleep 30

          # Status pruefen
          STATUS=$(curl -s \
            "${{ secrets.QAS_ENDPOINT }}/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER" \
            -u "${{ secrets.DEPLOY_USER }}:${{ secrets.DEPLOY_PASSWORD }}" \
            | jq -r '.status')

          if [ "$STATUS" != "IMPORTED" ]; then
            echo "Deployment failed with status: $STATUS"
            exit 1
          fi

  # Stage 3: Deploy to PRD (manuell)
  deploy-prd:
    name: Deploy to PRD
    needs: deploy-qas
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: production

    steps:
      - name: Create Release Tag
        run: |
          VERSION="v${{ github.run_number }}"
          git tag -a "$VERSION" -m "Release $VERSION"
          git push origin "$VERSION"

      - name: Pull to PRD System
        run: |
          curl -X POST \
            "${{ secrets.PRD_ENDPOINT }}/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER/pull" \
            -u "${{ secrets.DEPLOY_USER }}:${{ secrets.DEPLOY_PASSWORD }}" \
            -H "Content-Type: application/json" \
            -d '{"branch": "main", "tag": "v${{ github.run_number }}"}'

Azure DevOps Pipeline

trigger:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  - group: abap-credentials

stages:
  - stage: Test
    displayName: 'Test & Quality'
    jobs:
      - job: UnitTests
        displayName: 'ABAP Unit Tests'
        steps:
          - task: CmdLine@2
            displayName: 'Run ABAP Unit Tests'
            inputs:
              script: |
                curl -X POST \
                  "$(ABAP_DEV_ENDPOINT)/sap/bc/adt/abapunit/testruns" \
                  -u "$(ABAP_USER):$(ABAP_PASSWORD)" \
                  -H "Content-Type: application/xml" \
                  -d '<aunit:runConfiguration>...</aunit:runConfiguration>'

  - stage: DeployQAS
    displayName: 'Deploy to QAS'
    dependsOn: Test
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployToQAS
        displayName: 'Deploy to QAS'
        environment: 'QualityAssurance'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: CmdLine@2
                  displayName: 'Pull to QAS'
                  inputs:
                    script: |
                      curl -X POST \
                        "$(ABAP_QAS_ENDPOINT)/sap/bc/cts_abapvcs/repository/$(COMPONENT)/pull" \
                        -u "$(DEPLOY_USER):$(DEPLOY_PASSWORD)"

  - stage: DeployPRD
    displayName: 'Deploy to PRD'
    dependsOn: DeployQAS
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployToPRD
        displayName: 'Deploy to PRD'
        environment: 'Production'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: CmdLine@2
                  displayName: 'Pull to PRD'
                  inputs:
                    script: |
                      curl -X POST \
                        "$(ABAP_PRD_ENDPOINT)/sap/bc/cts_abapvcs/repository/$(COMPONENT)/pull" \
                        -u "$(DEPLOY_USER):$(DEPLOY_PASSWORD)" \
                        -d '{"tag": "$(Build.BuildNumber)"}'

Hotfix-Workflow

Fuer dringende Produktivkorrekturen:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         Hotfix-Workflow                                      │
│                                                                              │
│  1. Hotfix-Branch von main erstellen                                        │
│     ┌──────────┐                                                            │
│     │   main   │──────────────────────────────────────────────────────      │
│     └────┬─────┘                                                            │
│          │                                                                   │
│          │ branch                                                            │
│          ▼                                                                   │
│     ┌────────────────────┐                                                  │
│     │ hotfix/price-calc  │                                                  │
│     └────────────────────┘                                                  │
│                                                                              │
│  2. Fix entwickeln und testen (im DEV-System)                               │
│                                                                              │
│  3. Direkt in main mergen (nach Review)                                     │
│     ┌──────────┐                                                            │
│     │   main   │◄─────────── merge ────────── hotfix/price-calc             │
│     └────┬─────┘                                                            │
│          │                                                                   │
│  4. Sofort in QAS und PRD deployen                                          │
│          │                                                                   │
│          ├──────────► QAS (Pull)                                            │
│          │                                                                   │
│          └──────────► PRD (Pull mit Tag)                                    │
│                                                                              │
│  5. Hotfix in develop zurueckmergen                                         │
│     develop ◄─────────── merge ────────── main                              │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Rollback-Szenarien

Rollback ueber Git Tag

┌────────────────────────────────────────────────────────────────────────────┐
│  Rollback to Previous Version                                               │
│                                                                             │
│  Component: ZCUSTOM_ORDER                                                  │
│  Current Version: v1.3.0 (problematic)                                     │
│  Target Version: v1.2.0 (stable)                                           │
│                                                                             │
│  Available Tags:                                                            │
│  ○ v1.3.0   2026-02-14   feat: Add credit limit validation                 │
│  ● v1.2.0   2026-02-10   fix: Currency conversion                          │
│  ○ v1.1.0   2026-02-05   feat: Order history                               │
│                                                                             │
│  Action:                                                                    │
│  1. Checkout Tag v1.2.0 in PRD                                             │
│  2. Objekte werden auf Stand v1.2.0 zurueckgesetzt                         │
│                                                                             │
│  [Checkout Tag]  [Cancel]                                                   │
└────────────────────────────────────────────────────────────────────────────┘

Programmtisches Rollback

" Rollback-Logik fuer Automatisierung
" (wird typischerweise ueber CI/CD ausgefuehrt)

CLASS zcl_transport_rollback DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS:
      rollback_component
        IMPORTING iv_component   TYPE string
                  iv_target_tag  TYPE string
        RETURNING VALUE(rv_success) TYPE abap_bool.

ENDCLASS.

CLASS zcl_transport_rollback IMPLEMENTATION.

  METHOD rollback_component.
    " 1. gCTS API aufrufen fuer Tag-Checkout
    DATA(lo_destination) = cl_http_destination_provider=>create_by_url(
      i_url = |http://localhost:50000/sap/bc/cts_abapvcs/repository/{ iv_component }/checkout| ).

    DATA(lo_client) = cl_web_http_client_manager=>create_by_http_destination(
      i_destination = lo_destination ).

    " Request Body
    DATA: BEGIN OF ls_request,
            tag TYPE string,
          END OF ls_request.
    ls_request-tag = iv_target_tag.

    DATA(lv_json) = /ui2/cl_json=>serialize(
      data        = ls_request
      compress    = abap_true
      pretty_name = /ui2/cl_json=>pretty_mode-camel_case ).

    DATA(lo_request) = lo_client->get_http_request( ).
    lo_request->set_header_field( i_name = 'Content-Type' i_value = 'application/json' ).
    lo_request->set_text( lv_json ).

    DATA(lo_response) = lo_client->execute( if_web_http_client=>post ).

    rv_success = xsdbool( lo_response->get_status( )-code = 200 ).

    lo_client->close( ).
  ENDMETHOD.

ENDCLASS.

Best Practices

Do’s

Empfehlung	Begruendung
Feature Branches nutzen	Isolierte Entwicklung, einfaches Review
Konventionelle Commits	Klare Historie (feat:, fix:, refactor:)
Pull Requests fuer alle Aenderungen	Code Review, Quality Gates
Automatisierte Tests vor Merge	Fehler frueh erkennen
Tags fuer Releases	Reproduzierbare Deployments
Separate Environments	DEV/QAS/PRD Trennung
CI/CD Pipeline	Automatisierte, reproduzierbare Deployments

Don’ts

Vermeiden	Problem
Direkter Push auf main	Keine Review-Moeglichkeit
Fehlende Tests	Fehler erst in Produktion erkannt
Manuelle Deployments	Fehleranfaellig, nicht reproduzierbar
Ueberspringen von QAS	Ungetesteter Code in Produktion
Fehlende Rollback-Strategie	Lange Ausfallzeiten bei Problemen

Troubleshooting

Haeufige Probleme

Problem	Ursache	Loesung
”Pull failed”	Git-Authentifizierung	Credentials im Destination Service pruefen
”Activation error”	Abhaengigkeitsfehler	Fehlende Components klonen
”Merge conflict”	Parallele Aenderungen	Konflikt im Git-Repository loesen
”Object locked”	Anderer Benutzer bearbeitet	Sperre in System freigeben
”Version mismatch”	Unterschiedliche Commits	Pull auf allen Systemen ausfuehren

Diagnose-Kommandos

# Git-Status der Component pruefen
curl -s "$ABAP_ENDPOINT/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER" \
  -u "$USER:$PASSWORD" | jq .

# Commit-Historie abrufen
curl -s "$ABAP_ENDPOINT/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER/log" \
  -u "$USER:$PASSWORD" | jq .

# Branch-Liste abrufen
curl -s "$ABAP_ENDPOINT/sap/bc/cts_abapvcs/repository/ZCUSTOM_ORDER/branches" \
  -u "$USER:$PASSWORD" | jq .

Weiterführende Themen

gCTS: Git-enabled CTS - Detaillierte gCTS-Konfiguration
CI/CD mit ABAP Cloud - Automatisierte Pipelines
Software Component Management - Components strukturieren
ABAP Test Cockpit - Code-Qualitaet sicherstellen

Zusammenfassung

Transport Management auf SAP BTP basiert auf modernen DevOps-Prinzipien:

Git-basierter Transport ersetzt klassische Transportauftraege
Branching-Strategien ermoeglichen parallele Entwicklung
Pull Requests sichern Code-Qualitaet durch Review
CI/CD-Pipelines automatisieren Tests und Deployments
Tags markieren Releases fuer reproduzierbare Deployments
Rollback ist jederzeit durch Checkout frueherer Tags moeglich

Der Uebergang vom klassischen CTS zu gCTS mag anfangs ungewohnt sein, bietet aber erhebliche Vorteile: bessere Nachvollziehbarkeit, einfachere Parallelentwicklung und Integration in moderne DevOps-Workflows.