La risposta al tuo problema è duplice.
TL; DR: Usa DTAP e implementa un VCS.
In primo luogo, in un ambiente aziendale mai vuoi essere codificato direttamente sul server. Anche se non è l'ambiente live, avere più persone che modificano i file nello stesso ambiente ti dà una possibilità molto alta di modifiche in conflitto, il che porta a risultati imprevedibili. L'implementazione completa di DTAP ti aiuterà a risolvere questo problema.
DTAP sta per "Sviluppo, test, accettazione, produzione" e viene utilizzato per descrivere un sistema in cui ci sono 4 posizioni separate in cui il codice può essere. La separazione è progettata per proteggere la produzione dal maggior numero possibile di problemi:
Prima il codice viene eseguito e testato su Sviluppo (che può essere una macchina separata ma spesso è semplicemente il PC dello sviluppatore).
Se lo sviluppatore è soddisfatto del suo lavoro, il codice passa all'ambiente Test, dove qualcun altro (idealmente un tester dedicato ma un altro sviluppatore può lavorare) proverà il codice.
Se questa fase di test non rileva problemi, il codice passa a Acceptance, dove il lato "business" dell'azienda testerà il codice. Questo può essere il tuo cliente se la tua azienda produce un prodotto per un'altra parte o può essere un reparto diverso che è in contatto con ciò che il prodotto dovrebbe fare per soddisfare le esigenze dei clienti finali.
Solo se accettano il codice, il codice passerà all'ambiente di produzione, che è l'ambiente live.
In secondo luogo, per tenere traccia delle modifiche e prevenire i problemi che sorgono quando più persone modificano la stessa area del codice allo stesso tempo, è necessario implementare un VCS (Sistema di controllo versione) nella propria organizzazione che terrà traccia di tutte le modifiche a tutti i file (gli esempi sono SVN, Git e Mercurial). Questi sistemi ti consentiranno anche di eseguire il rollback delle modifiche se si scopre di aver fatto un errore. Per semplificarti la vita, potrebbe valere la pena utilizzare il tuo sistema di scelta con un account in un servizio come Bitbucket che ti consentirà di utilizzare la loro interfaccia per il processo di combinazione del lavoro di uno sviluppatore con un altro. Tutti i tuoi sviluppatori dovranno concordare la strategia specifica da utilizzare per unire il codice nello stato che passerà dallo sviluppo al prossimo ambiente, ma non sovraccaricherò la mia risposta.
Quando dici che le persone non tecniche stanno modificando l'ambiente di test, spero che intendi che apportano modifiche alla configurazione e / o al contenuto, non ai file reali. Le persone non tecniche dovrebbero mai toccare il codice del sito web, dopotutto se non hanno idea di quello che stanno facendo potrebbero accidentalmente rompere qualcosa!
Per quanto riguarda la questione della compatibilità e l'affermazione che le persone non tecniche non possono aspettarsi di mantenere il proprio server Apache, ci sono diverse opzioni che posso vedere. Un'opzione è avere una persona che gestisca l'installazione di questi server per tutte le parti coinvolte, ma questo può essere un lavoro a tempo pieno e potrebbe non essere adatto alla tua organizzazione per avere una tale persona. L'alternativa è usare uno degli strumenti disponibili come Vagrant o Docker, che consentirà a una persona tecnica di creare una "immagine" che avrà l'ambiente di lavoro (che sarà tipicamente basato su Linux) e che l'immagine può essere distribuita a tutti sviluppatori in modo che possano eseguirlo sul proprio computer. Se è necessario apportare aggiornamenti all'architettura, questa persona aggiorna l'immagine e la distribuisce nuovamente agli sviluppatori.
Parere personale:
Dal post originale deduco che la tua azienda ha superato lo stato di "solo 2 persone stanno lavorando sul sito comunque, quindi non importa quello che facciamo". Questi concetti che propongo sono ampiamente accettati come buone pratiche, come potete vedere dalla mia spiegazione otterrete MOLTI controlli aggiuntivi sulla qualità del prodotto, al compromesso dell'introduzione di una complessità aggiuntiva relativamente piccola al vostro processo. Un sistema di controllo della versione come Git o Mercurial può sembrare intimidatorio, ma a mio avviso, con un po 'di formazione letteralmente chiunque può imparare come lavorarci correttamente. Tutto ciò che richiede è un atteggiamento di volontà da apprendere invece di vedere il sistema come un nemico che ti impedisce di portare a termine il tuo lavoro, l'ultimo dei quali è purtroppo molto più comune di quanto dovrebbe essere. Imparando a utilizzare correttamente lo strumento, risparmierai il tempo che dovresti dedicare a correggere gli errori e ad ordinare manualmente come il lavoro di più persone debba essere combinato nel codice.