I’ll tell you about mine:

For source control and the code I’m bound to use transaction SE80 (or one of its siblings like SE24), which is a SAP base transaction for ABAP development.

Here I have some sort of version tracking which allows to compare different versions of the code. Positive to remark is the feature to compare code across the system landscape, to compare code of the productive environment with the one in the dev. environment.

The ABAP editor offers sort of syntax highlighting and suggestions for completion on key words and variables. Code consistency is checked with Alt-F2.

I don’t know about other debuggers, but I like what I have with SAP’s new debugger. All the fields and run-time information directly accessible. I could get insight into table content and manipulate every attribute.

What I never used is the Code Inspector, which, ok, inspects the code, unreached passages, infinite loops thinks like this. The inspection could be scheduled, so sort, of CI as continuous integration is possible. Also scheduable from the Code Inspector is the execution of unit tests.

Finally I need to mention that we do a very straight forward coding in our BW system. No super generic stuff. In general structural and type information are at hand and we simply add some business logic. Beside this there are some neural core components like changed data capturing, or generating surrogate keys. More or less we are forced by SAP to use ABAP Objects, but not in the OO way.

Bug tracking depends on the systems. Unwanted features visible to the customer are tracked by central, and group wide Pergrine Service Center. Those are called incidents, get an priority and development team assigned, and are to be solved. Bugs in the development system are tracked by using… words. So the small team responsible for a set of applications in SAP BW know, because hear, that there is an issue.

That my infrastructure stack. As I have no options this is my preferred one

Go ahead, Olli!