C'è la migliore pratica di "il codice dev non lo rende mai in produzione". C'è anche la migliore pratica di "tutte le build sono le stesse". Sfortunatamente, questi due possono rendere alcune decisioni difficili e compromessi tra le due migliori pratiche.
Se devi comprometterli, tutte le build sono le stesse è probabilmente la migliore procedura migliore. In parte perché significa che puoi inserire una build di produzione nell'ambiente di sviluppo, attivare gli interruttori appropriati ed essere in grado di esaminare gli interni con gli strumenti di sviluppo disponibili.
Un esempio di questo è come funziona la registrazione. LOG.debug("foo"); viene eseguito solo negli ambienti in cui è stata abilitata la configurazione di debug per la registrazione, che non è produzione.
All'interno di Java EE, una delle impostazioni disponibili è quella delle impostazioni server / vm. Con Java, puoi utilizzare l'opzione -D sul vm per impostare determinate proprietà che possono essere interrogate in fase di esecuzione con System.getProperty("propname");
Con questo approccio, si potrebbero cambiare le opzioni della VM per avere -Djmoreno.debug , il che significa che è in esecuzione in un ambiente di sviluppo.
Questo può anche essere utile quando si hanno più macchine in produzione che hanno bisogno di proprietà (ad esempio percorsi di file) ... e si desidera distribuire solo una copia per entrambe - cambia l'opzione in modo che ogni vm ne conosca la percorso del file e quindi il codice rimane coerente tra le due distribuzioni di produzione.
Non è tanto un problema di "best practice", ma piuttosto un design inevitabile per evitare le cattive pratiche.
Per il caso specifico di "ecco la funzionalità che esiste solo in dev" con un ambiente JEE - incoraggerei a cercare in un file dbfiddle.war che viene inserito nello sviluppo .ear - non si fa strada in altri file .ear. In questo modo la separazione delle funzionalità di sviluppo da altre funzionalità è chiara e distinta: non può perdere accidentalmente in altri ambienti con un bit di codice errato o impostazione del server (configurazione errata - sì, ma è più facile da controllare - basta aprire il .ear and look).
L'altra cosa che (se non ha bisogno di essere raggruppata in .ear) sarebbe solo scrivere un'applicazione stand-alone - non distribuirla nemmeno sul server. Basta eseguirlo. Idealmente, qualsiasi logica di business di cui ha bisogno è opportunamente separata in un .jar che può essere utilizzato sia dal codice stand-alone che dal codice JEE (piuttosto che essere strettamente collegato al codice JEE).