gCTS Developer Workflow Guide

[tariqueahmad275]

For ABAP Developers Transitioning from Traditional CTS

1. GENERAL FLOW: DEV → QAS → PRD
Traditional CTS (What You Know)
DEV ──[Transport Request]──► QAS ──[Transport Request]──► PRD
(STMS) (STMS)

You create a transport request in DEV
You release it
Transport admin imports it into QAS via STMS
After testing, the same TR is imported into PRD
The transport request IS the delivery vehicle

gCTS (What Changes)
DEV ──[commit/push to Git]──► Git Repo ◄──[pull]── QAS
◄──[pull]── PRD

You still create transport requests in DEV (this doesn't change!)
When you release the transport request, gCTS automatically commits the changed objects to the Git repository
There is NO automatic import into QAS — someone must pull from Git into QAS
Same for PRD — someone must pull the desired commit/branch

Step-by-Step: A Normal Development Cycle
In DEV System (Developer's perspective — barely changes)

Open ADT (Eclipse), connect to DEV
Create/modify your ABAP object (class, CDS view, etc.)
Assign it to a transport request — yes, exactly like before
Do your development work
Release the transport task (your subtask) — same as before
Release the transport request — same as before

What happens behind the scenes at release:

gCTS detects the release
The Observer Job (a background job running in DEV) picks up the released TR
It serializes the objects and commits + pushes them to the remote Git repository
The commit message typically contains the TR number and description

Key difference: In traditional CTS, releasing a TR queues it for import via STMS.
In gCTS, releasing a TR triggers a Git commit. There's no STMS import queue.

Moving to QAS (Basis Admin or Release Manager)

Open the Git-enabled CTS Fiori app on the QAS system
Open the relevant repository
You see a list of commits (each one = a released TR from DEV)
Select the commit you want to deploy
Click Pull
gCTS deserializes the objects and imports them into the QAS ABAP system

Traditional CTS equivalent: This replaces the STMS import step. Instead of importing a specific TR, you're pulling a specific Git commit.
Moving to PRD (Same process)

Open Git-enabled CTS Fiori app on PRD
Open the repository
Pull the tested commit (or a release branch)
Objects are imported into PRD

What the Fiori App Shows You
┌─────────────────────────────────────────────────┐
│ Git-enabled CTS │
│ │
│ Repository: Z_MY_PROJECT │
│ Branch: main │
│ Current Commit: abc1234 │
│ │
│ Commit History: │
│ ┌─────────────────────────────────────────┐ │
│ │ def5678 - Fix ALV output - TR DEVK900123│ ◄──── Latest │
│ │ abc1234 - Add new report - TR DEVK900122│ ◄──── Current │
│ │ 789abcd - Initial setup - TR DEVK900121│ │
│ └─────────────────────────────────────────┘ │
│ │
│ [Pull] [Checkout Branch] │
└─────────────────────────────────────────────────┘

Current Commit = what's currently active in this system's ABAP runtime
Pull = bring a commit (and everything before it) into this system
You pull to a specific commit — all commits UP TO that point come in

2. BUG FIX FLOW: Fixing an Object in PRD
Scenario
Object ZCL_SALES_ORDER exists in PRD. A bug is found. Developer needs to fix it.
Does the ENTIRE object move, or just the delta?
The entire object moves. This is critical to understand.
AspectTraditional CTSgCTSWhat travelsThe entire object (full source)The entire object (full source)GranularityTransport request levelCommit level (= released TR)Delta?No — full object replacementNo — full object in each commit
In Git terms: the repository stores the complete serialized source of each object at each commit. When you pull a commit into QAS/PRD, the full object is deserialized and overwrites what's there.
This is the same as traditional CTS — when you transport ZCL_SALES_ORDER, the entire class moves, not just the changed method.
Multiple Commits on the Same Object
Scenario: Developer makes 3 bug fixes on ZCL_SALES_ORDER across 3 separate TRs.
Commit 1 (TR DEVK900201): Fix method VALIDATE_ORDER
Commit 2 (TR DEVK900202): Fix method CALCULATE_TAX
Commit 3 (TR DEVK900203): Fix method CHECK_STOCK
What happens when you pull into QAS?

If you pull Commit 3: You get ALL three fixes. Pulling a commit means
you get everything up to and including that commit. The system will have
the state of the object as of Commit 3.
If you pull Commit 2: You get fixes 1 and 2, but NOT fix 3.
You cannot cherry-pick just Commit 2 and skip Commit 1.
Pulls are sequential — you move forward to a point in history.

Traditional CTS comparison:
In traditional CTS, you could theoretically import TR 900202 without 900201
(though this would often cause issues). In gCTS, the sequential nature is
enforced — you always move forward to a specific commit, getting everything
before it.
The Bug Fix Workflow: Step by Step
Timeline:
─────────────────────────────────────────────────────────

1. Bug reported in PRD
│
2. Developer opens ADT → connects to DEV
│
3. Developer modifies ZCL_SALES_ORDER
├── Creates/uses transport request DEVK900201
├── Makes the fix
├── Activates (Ctrl+F3)
├── Tests locally in DEV
│
4. Developer releases TR DEVK900201
│ └── gCTS Observer Job automatically commits + pushes to Git
│
5. In QAS: Basis admin opens gCTS Fiori app
├── Sees new commit for DEVK900201
├── Clicks Pull
├── ZCL_SALES_ORDER is updated in QAS
│
6. QAS testing happens
│
7. In PRD: After approval, admin opens gCTS Fiori app on PRD
├── Pulls the same commit
├── ZCL_SALES_ORDER is updated in PRD
│
8. Bug is fixed in production
Who Does What
ActionWhoWhereToolDevelop & fixDeveloperDEVADT (Eclipse) or SE80Release TRDeveloperDEVADT or SE01Commit to GitAutomaticDEV (Observer Job)BackgroundPull to QASBasis Admin / Release MgrQASgCTS Fiori AppTestQA TesterQASVariousPull to PRDBasis Admin / Release MgrPRDgCTS Fiori App
Using the Fiori App for the Bug Fix
On the QAS system, the admin:

Logs into Fiori Launchpad on QAS
Opens "Git-enabled CTS" app
Selects the repository (e.g., Z_WORKBENCH)
Sees the commit list — the new commit from the developer's released TR is visible
Clicks on the commit → sees which objects are included
Clicks Pull → the commit is pulled, objects are imported
Checks the pull log for success/errors

Same process repeats on PRD after QAS sign-off.

3. DEV STARTING POINT: Developer's Morning Routine
Traditional CTS: What You Did Before

Log into DEV (ADT or SAP GUI)
Find or create your object
Lock it in a transport request
Start coding
No concept of "pulling" — DEV just has whatever was developed there

gCTS: What Changes (and What Doesn't)
The developer does NOT pull in DEV.
This is the most common misconception. Here's why:

DEV is the source of truth — code originates here
The Git repository receives commits FROM DEV
You don't pull into DEV from Git (in the standard flow)
DEV always has the latest state because that's where development happens

Developer's First Action in DEV
It's the same as before:

Open ADT → connect to DEV system
Find your package / object
If creating new: Right-click package → New → [Object Type]
If modifying existing: just open it and start editing
The system prompts for a transport request → create or select one
Code, activate, test
When done: release the TR

There is no "git pull" step in DEV for normal development.
Conflict Scenario: Two Developers, Same Object
Scenario: Developer A and Developer B both need to change ZCL_SALES_ORDER.
In Traditional CTS

Dev A locks the object in TR 900301
Dev B tries to modify → gets a lock error ("Object locked in request DEVK900301 by USER_A")
Dev B must wait, or get Dev A to release, or use a shared TR

In gCTS — It Works the Same Way!
The ABAP lock mechanism hasn't changed. gCTS doesn't add Git-style parallel
editing to the ABAP development experience.

Dev A locks ZCL_SALES_ORDER in their TR
Dev B gets the same lock error
Dev B must wait for Dev A to release

The Git part only kicks in AFTER the TR is released. During active
development, the workflow is identical to traditional CTS.
However, there IS a scenario where gCTS changes things:
Parallel Development with Branches (Advanced)
If your team uses branches (available from S/4HANA 2020):
main branch ─────●─────●─────●──────
\
feature branch ─────●─────●─────

You can create a feature branch in the gCTS Fiori app
DEV system checks out the feature branch
Development happens on that branch
When ready, the branch is merged back to main
QAS/PRD pull from main

But this is an advanced setup. Most teams start with a single main branch,
which makes gCTS feel very similar to traditional CTS.

Quick Reference: Traditional CTS vs gCTS
TopicTraditional CTSgCTSDev creates TRYesYes (unchanged)Dev releases TRQueues for STMS importTriggers Git commitMove to QASSTMS import by adminPull via Fiori appMove to PRDSTMS import by adminPull via Fiori appObject lockingTR-based locksTR-based locks (same)Rollback in QAS/PRDRe-import old TR or manual fixPull an older commitDevelopment toolADT / SE80ADT / SE80 (unchanged)Transport toolSTMS (tcode)gCTS Fiori AppWhere code livesTransport files (.cofiles/.data)Git repositoryVisibilityTransport logsGit commit historyParallel devNot natively supportedBranches (2020+)

The Rollback Advantage (Why gCTS Matters)
This is where gCTS genuinely improves life:
Traditional CTS rollback:

Object broken in QAS after import
You must fix it in DEV, create new TR, release, import again
Or manually revert in QAS (risky, not recommended)

gCTS rollback:

Object broken in QAS after pull
Open gCTS Fiori app on QAS
Find the previous good commit
Pull that commit → system reverts to that state
No need to touch DEV at all for the rollback

This is one of the biggest practical benefits of gCTS.

Summary: What Actually Changes for a Developer
Almost nothing in daily coding. You still:

Use ADT or SE80
Create transport requests
Lock objects in TRs
Activate objects
Release TRs

What changes:

After release, your code goes to Git (automatically)
Moving to QAS/PRD uses the Fiori app "Pull" instead of STMS "Import"
You can see full commit history in the Fiori app
Rollbacks become much easier
Branching is possible (if your team adopts it)