La distribuzione di funzionalità appena sviluppate direttamente in un sistema di produzione dal vivo è estremamente rischiosa, in qualsiasi lingua o piattaforma tu scelga, perché non sei in grado di testare le nuove funzionalità o modifiche prima che gli attuali utenti del sistema siano esposti a loro.
Con questo in mente, diventa chiaro il motivo per cui dovresti almeno separare l'ambiente di produzione e sviluppo e scegliere tempi appropriati per l'implementazione (trasporto) dallo sviluppo alla produzione.
Tuttavia, ci sono anche buoni motivi per separare ulteriormente, e avere anche un ambiente di test. Poiché i sistemi complessi di solito richiedono un test manuale per controllarlo completamente (che può essere eseguito anche da un team di tester e / o dal cliente), disporre di un ambiente di test separato consente di avere una build stabile del sistema per il manuale / integrato / l'accettazione test, mentre lo sviluppo è libero di continuare nel proprio ambiente. Con "stabile", non solo significa che le funzionalità sono già state testate da parte degli sviluppatori (nell'ambiente di sviluppo), ma anche per SAP R / 3, significa che non ci sarà dumps perché qualcuno sta attivando lo sviluppo oggetti mentre ci sono utenti che li eseguono ( LOAD_TYPE_VERSION_MISMATCH ).