Quali sono gli svantaggi di lasciare i tag di automazione nel codice di produzione?

Naviga le tue risposte
2

Ho impostato i tag di debug per il test automatico di un'applicazione Web basata su GWT. Ciò comporta l'attivazione di tag / attributi ID debug personalizzati per gli elementi nella sorgente dell'app. È un compito non banale, in particolare per le applicazioni Web più grandi e complesse. Recentemente si è discusso se l'attivazione di tali debug ID è una buona idea da fare a tutti i livelli.

Attualmente gli ID di debug vengono attivati solo nei server di sviluppo e di test, non in produzione. Sono stati sollevati dei punti che l'abilitazione degli id di debug fa sì che le prestazioni subiscano un successo e che gli id di debug in produzione possano portare a problemi di sicurezza.

Quali sono i vantaggi di fare questo? Esistono rischi significativi per l'attivazione dei tag di debug nel codice di produzione?

    
posta joshin4colours 29.11.2012 - 02:45
fonte

4 risposte

2

La penalizzazione delle prestazioni non è compresa nell'intervallo osservabile. Abilitare gli ID di debug in GWT è semplice come attivare un tag ereditato in GWT. Non è banale solo per alcuni widget composti o in caso di logica personalizzata per griglie o albero.

  1. Costruisci con gli id di debug ed esegui l'automazione basata sul selenio.
  2. Crea senza id di debug ed esegui test di sanità manuale.
risposta data 29.11.2012 - 03:23
fonte
1
> What are the downsides of leaving automation tags in production code?

Sono d'accordo con @Sachin Shekhar R che le prestazioni e la penalità di spazio sono marginali.

L'unico problema a cui posso pensare è che i bot possono usare il tuo sito molto più facilmente, se ci sono tag sui tuoi campi di input e output importanti. se questo può diventare un problema o meno dipende dal tuo caso d'uso.

Almeno il login e il modulo di registrazione del cliente devono essere protetti dai bot di Agaist.

    
risposta data 17.12.2012 - 08:40
fonte
0

Questi flag dovrebbero essere attivati solo in DEV ma sembra che tu stia utilizzando il QA come istanza di integrazione di build. PRD assolutamente no. Se c'è un problema con PRD è necessario ripristinarlo in QA, se hai un progetto in corso che sta usando il QA, allora costruisci un'altra serie di istanze.

Devo lottare a denti stretti con la maggior parte dei clienti, ma la segregazione e le politiche di promozione adeguate devono essere messe in atto sin dall'inizio. Il controllo qualità deve essere una valutazione reale delle risorse di sviluppo con funzionalità complete di dati. Gli ambienti DEV sono usa e getta e il PRD non viene toccato.

Non si dovrebbe mai modificare direttamente il PRD a meno che non sia stata effettuata una valutazione impatto / downtime ed è stata approvata. Il modo migliore per rispondere alla tua domanda sarebbe quello di ripristinare il PRD in un ambiente simile e iniziare a eseguire test delle prestazioni contro di esso.

Tuttavia è improbabile che se i flag di debug causano ritardi evidenti, è più probabile che l'hardware su cui gli ambienti sono seduti sia sottodimensionato o sovraccarico.

    
risposta data 15.12.2012 - 19:53
fonte
0

Mantenere i tag di debug nel codice utilizzato nell'ambiente di produzione non è una cattiva idea. Tuttavia, questi devono essere abilitati solo come e quando richiesto, in caso di problemi con i clienti, ecc., Non è consigliabile lasciare la modalità di debug su macchina di produzione. Inoltre, se è necessario implementare la modalità di debug, è necessario definire i livelli di debug e la modalità di debug di livello superiore può essere abilitata nell'ambiente di produzione con la possibilità di modificare tale livello come e quando necessario.

    
risposta data 16.12.2012 - 16:24
fonte

Leggi altre domande sui tag

Quali sono gli avvertimenti del sistema di eventi costruiti su Messenger piuttosto che su eventi .NET classici? Devo gestire l'autenticazione da solo se l'alternativa è molto bassa nell'usabilità e sto già gestendo i ruoli?