SAP Development system
The Development (DEV) system is where all configuration and custom code originate. It is the first system in the landscape, the workshop in which consultants and developers build changes that will later be tested and moved to production.
DEV is where consultants customise in SPRO and developers write ABAP and build Fiori apps, with every change recorded in a transport request that carries it to QAS and PRD. It holds a customising client, a sandbox client and sometimes a golden client. DEV needs discipline in transports and naming, and it holds sample data; realistic testing belongs in QAS.
- Watch out: Configuring in the wrong client.
What happens in DEV
DEV is where functional consultants perform customizing (in SPRO) and developers write ABAP, build Fiori apps and create objects. Every change is recorded in a transport request, which becomes the vehicle to carry that change onward to QAS and PRD.
Clients within DEV
- A customizing client where configuration is done and captured in transports.
- A sandbox client for free experimentation (not transported).
- Sometimes a golden/config-reference client kept clean.
DEV discipline
Because everything downstream depends on it, DEV needs discipline: changes captured in well-described transports, developments following naming standards, and configuration done in the correct client. Sloppy DEV practices cause chaotic transports and painful imports later.
DEV is not for realistic data
DEV typically holds minimal or sample data; realistic volumes and integration testing belong in QAS. DEV is about building, not proving.
Common pitfalls
- Configuring in the wrong client.
- Poorly described transports that are impossible to track.
- Testing seriously in DEV instead of QAS.