Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

Git and transports together: a workflow you can sign off

9 min

Listen to this lesson

0:00 / 14:44

Git and CTS answer different questions, so the workflow has to say which one is authoritative for what. At Contoso, the rule fits on one line: git is the record of review; the transport request is the vehicle of deployment; no request is released until its pull request is merged. This lesson turns that rule into steps, roles and evidence.

The Contoso workflow

  1. Open a dedicated requestKenji's developer creates a workbench request in CMD for the ticket; the agent works only on objects in that request
  2. Agent changes and checksThe agent edits through ADT, activates, runs ATC and ABAP Unit; the developer reads every change
  3. Push to a branchThe developer stages the objects in abapGit and pushes branch cmdk<number>-<topic> with the request number in the comment
  4. Pull request and reviewTemplate filled, checks attached, two approvals including the package owner
  5. Mergemain now matches the reviewed state in CMD
  6. Release the requestThe developer releases tasks and request; ATC runs on release
  7. Import and testLuis imports to CMQ client 100; Priya's team tests; Luis imports to CMP in the release window
Seven steps from ticket to production; the pull request merge gates the release.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-204
Responsibilities by lane: the agent never crosses into review or release.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-204

Why release waits for merge

Once a request is released, its object list is frozen and the import path opens. If review happens after release, a rejected change has to be reverted with a new request, and the bad version may already be in CMQ's import queue. Waiting for the merge keeps the cheapest fix available: change the code in CMD and push again. It also makes one check trivial for Luis: before importing, he confirms that the request number appears in a merged pull request.

Keeping git and the system in step

  • Drift: someone changes an object in CMD without pushing. abapGit shows it as changed against main the next time anyone opens the repository; treat that as a finding, not noise.
  • Rejected changes: if review rejects a change, revert it in CMD (the agent can propose the revert; a person approves) and push the revert, so main and CMD agree.
  • Emergency changes: Contoso's emergency path still builds in CMD and transports with an emergency approver; the pull request is created and approved retrospectively within one working day.
  • Pulls into CMD: only for bringing reviewed code in (for example from a sandbox), never to overwrite work in progress.
  1. Day 1, 09:00Request CMDK900417 openedTicket: block closing an agreement with open items
  2. Day 1, 11:30Agent change completeBehavior pool and two test methods; ATC clean, ABAP Unit green
  3. Day 1, 12:00Pull request openedBranch cmdk900417-open-items; template filled
  4. Day 1, 16:00Approved and mergedKenji (package owner) and a second developer approve
  5. Day 2, 08:30Request releasedATC on release passes; Luis imports to CMQ
  6. Day 4Test sign-offPriya's team passes the closing scenarios; import to CMP in the release window
A typical agent change at Contoso, from request to production.
The Sign-Off Table · thesignofftable.com/academy/sap-aid-204

Keeping the evidence

An auditor who asks "who approved this change to the core agreement closing logic?" a year from now should get the answer in minutes. Keep pull requests and their discussion for at least as long as you keep transport logs; don't delete merged branches' pull requests even when you delete the branches. Link both directions: the commit comment names the request, and the change ticket names the pull request. If Contoso later moves a package to gCTS, the history in git carries over, because the repository is the same; only the mechanism that creates commits changes.

What would you do?

Friday afternoon: a developer's agent change passed review, but the developer released the request <em>before</em> merging, and a reviewer has now asked for one more change. The request is in CMQ's import queue. What should happen?

What would you do?

Grace asks whether Contoso can skip git for "small" agent changes under 20 lines to save time. What do you recommend?

Key points
  • Git is the record of review; the transport request is the deployment vehicle.
  • Release only after merge, so rejected changes are fixed in CMD instead of chasing released requests.
  • Watch for drift between main and CMD; treat unpushed differences as findings.
  • Release managers check the merged pull request before importing.

Check your understanding · not graded

Lesson check

  1. 1. In Contoso's workflow, what must happen before a request with agent changes is released?

  2. 2. abapGit shows a CMD object as changed against main, but nobody opened a pull request. What is it?

  3. 3. How does Contoso handle an emergency change in this workflow?