Concept

[fabianlupa]

• Focus on 3 system landscape (DEV -> QAS -> PRD)
• Provide integration between Git platforms (GitHub/GitLab) and CTS
• Provide interfaces for remote ATC calls, filterable by PR content

---

• Use abapGit/background_modes transport-to-branch, but without automatic commits
• Each transport is a branch in Git
• Pull requests enable code review processes
• CI can be run on pull requests. ATC will have to be called on DEV. This results in conflicts for parallel developments, as errors of other branches could be reported back -> filter results on objects locked in transport (as a compromise, setting up a VM/container on demand is not realistic). Non AS ABAP CI tasks like abapLint can be executed within the CI container.
• Merging the PR will add the changes to master branch. A git hook should then release the transport.
• Importing the transport to QAS should be done manually. Because of this there is a delay between the state in master and QAS. Other than that master = QAS.
• Somehow prevent the CI on master to be run if there are "merged transports" that are not yet imported. Trigger CI manually from DEV once the transport is in QAS.
• ATC results on QAS do not need to be filtered
• Release versions should be created on QAS. I. e. create a release/tag on GitHub/GitLab, this triggers a TAG build on GitLab CI, GitLab CI triggers QAS to create a TOC of all objects in the repo and uploads it as a build artifact and attaches it to the release.
• Stateful integration tests with database persistence should be run on QAS, possibly on a separate client that can be rebuild on demand.

Problems:

• All class includes including all method implementations can be individually locked in transports while abapGit only versions one include for all definition and implementation. ADT used to be unable to edit only methods and locked the whole class. Maybe this behavior can re re-enabled?

[fabianlupa]

On AS ABAP Developer edition the CTS_*_FEEDBACK BAdIs are not called with the default TMS configuration. This can be solved by creating a virtual system, a transport route + layer and changing the transport layer of the package.

[fabianlupa]

Client handling:

• ci-lib customizing should be client independent because development with workbench objects and abapGit are also client independent
• Development is usually not done in client 000, there might be multiple development clients in DEV
• CTS_*_FEEDBACK is always called in client 000
• The application log customizing (SLG0) is client independent, but log entries created are only created in the current client.

-> CTS_*_FEEDBACK should call a handler using RFC on DEV with a fixed development client, logging in the handler can be done with BAL, error logging in the BAdI implementation should only use the syslog because no one will check SLG1 in client 000.

[fabianlupa]

Regarding LIMU-METH / CLASS locks: In SE01 there is a button to convert subojects into their parent "full" objects inside of a transport request. Unfortunately only works for TOC.

[larshp]

I'd like to know possible merge issues as soon as possible, so suggest having the tooling give an error if someone changes the same object in 2 different branches.

[fabianlupa]

I agree, merge conflicts would make things very difficult. For most object types the exclusive locks of workbench objects in transports should already be enough (assuming released transport = merged branch). For some subobjects or really anything where abapGit serializes one file for an object type for which individual parts can be transported on their own there needs to be some kind of lock mechanism or warning/error. IF_EX_CTS_REQUEST_CHECK~CHECK_BEFORE_ADD_OBJECTS should be able to do this.

[larshp]

Some years ago I made some drawings regarding different branching concepts, https://github.com/larshp/abapGit-flow If the transport is released, but not imported on all systems I'd like to keep the branch "open". And also discover if somebody changes something that is part of a non-imported transport, however it quickly gets complicated

[fabianlupa]

I thought about having a branch for each system and visualize the route transports take in git that way. But as you said it gets quite complex very fast. I'd already be happy if this works out. For keeping track of transports in GitLab/GitHub the generated comments and possibly PR/issue-labels or a generated wiki page with a table of transports and their status and links to Transport Organizer Web UI should be enough.