Qui ci sono tre problemi separati, non collegati, che sono entrambi opportunità per migliorare la gestione del team del tuo sito web. In ordine di difficoltà per l'implementazione, hai bisogno di (1) un server di test, (2) un'architettura migliorata per il tuo sito e (3) alcuni standard di codifica che il tuo team può essere costretto a seguire.
(1): implementa un server di prova
Se il tuo sito web è abbastanza importante da far funzionare più di un programmatore, è abbastanza importante creare un server di test dedicato. Il server può essere una macchina virtuale, se appropriato, ma NON DEVE essere amministrato dai tuoi programmatori, e DOVREBBE essere identico al tuo ambiente di produzione come fattibile pur non essendo la stessa macchina.
I tuoi sviluppatori possono programmare sui loro desktop o su una terza macchina di "sviluppo", ma il codice che va sul server di prova dovrebbe essere lì solo per il test, e dovrebbe essere in uno stato tale da poter essere interamente copiato o dal server di produzione senza alcuna modifica oltre a un riavvio del processo.
(2) Migliora l'architettura del tuo sito
Sembra che tu possa avere una grave mancanza di separazione tra design, codice e contenuto. Garantire che i vari componenti abbiano tutti lo stesso aspetto e aspetto è NOT lo stesso lavoro di scrittura di componenti sensibili per la gestione dei dati e, anche se eseguiti dallo stesso team, dovrebbero essere scritti in lavori completamente diversi sessioni e memorizzati in file completamente diversi.
Anche se si è trattato di un errore di comunicazione, il team che pensa di dover risolvere i problemi in una distribuzione e di non essere sicuro di come apportare tali correzioni è un'enorme bandiera rossa che farebbe una re-architettura. Mentre apporti le modifiche, puoi anche implementare migliori pratiche di test, come una batteria completa di unità, integrazione e test di sistema che possono essere eseguiti sul server di test dopo ogni commit effettuato.
(3) Adotta alcuni standard di codifica obbligatori
Mentre è assurdo pensare che si possa costringere tutti a scrivere il proprio codice sempre lo stesso, chiunque possieda il sito dovrebbe essere in grado di insistere sul fatto che tutto il lavoro futuro rispetti almeno un livello base di standardizzazione e chiarezza, sufficiente che il codice non dovrà essere abbandonato se un membro particolare della squadra lascia.
La documentazione e i commenti sono un buon inizio, mentre il codice pulito sarebbe migliore e un processo di miglioramento continuo e la proprietà del codice depersonalizzata sarebbero i migliori di tutti. Ma, anche più del precedente, questa è una domanda di gestione e non una domanda di programmatore.
Oh, e nel caso tu stia cercando la risposta più concreta di "come collaudo un sito web", la risposta migliore è "automaticamente, adottando un framework come QUnit , acquistando il software di prova di un appaltatore o scrivendo il tuo. "
Idealmente, il tuo meccanismo di test sarebbe qualcosa che è memorizzato nel codice del sito web stesso e può essere chiamato anche sul server di produzione (quando invocato localmente).