La respuesta a su problema es doble.
TL; DR: Use DTAP e implemente un VCS.
En primer lugar, en un entorno empresarial, nunca desea codificar directamente en el servidor. Incluso si no es el entorno en vivo, tener varias personas editando archivos en el mismo entorno le brinda una alta probabilidad de cambios conflictivos, lo que conduce a resultados impredecibles. La implementación completa de DTAP lo ayudará a resolver este problema.
DTAP significa "Desarrollo, Prueba, Aceptación, Producción" y se usa para describir un sistema en el que tiene 4 ubicaciones separadas donde puede estar el código. La separación está diseñada para proteger la producción de la mayor cantidad posible de problemas:
Primero, el código se ejecuta y se prueba en Desarrollo (que puede ser una máquina separada pero a menudo es simplemente la propia PC del desarrollador).
Si el desarrollador está satisfecho con su trabajo, el código pasa al entorno de prueba, donde otra persona (idealmente un probador dedicado, pero otro desarrollador puede trabajar) probará el código.
Si esta fase de prueba no encuentra problemas, el código pasa a la Aceptación, donde el lado "comercial" de la compañía probará el código. Este puede ser su cliente si su empresa fabrica un producto para un tercero, o puede ser un departamento diferente que esté en contacto con lo que debe hacer el producto para satisfacer las necesidades de los clientes finales.
Solo si aceptan el código, el código se moverá al entorno de producción, que es el entorno en vivo.
En segundo lugar, para realizar un seguimiento de los cambios y evitar los problemas que surgen cuando varias personas modifican la misma área del código al mismo tiempo, debe implementar un VCS (Sistema de control de versiones) en su organización que realizará un seguimiento de Todos los cambios a todos los archivos (ejemplos son SVN, Git y Mercurial). Estos sistemas también le permitirán revertir los cambios si resulta que cometió un error. Para hacer la vida más fácil, podría valer la pena usar el sistema de su elección con una cuenta en un servicio como Bitbucket que le permitirá usar su interfaz Para el proceso de combinar el trabajo de un desarrollador con otro. Todos los desarrolladores deberán acordar la estrategia específica que se utilizará para combinar el código con el estado que pasará del desarrollo al siguiente entorno, pero no sobrecargaré mi respuesta con eso.
Cuando dice que personas no técnicas están modificando el entorno de prueba, espero que se refiera a que realizan cambios en la configuración y / o el contenido, no en los archivos reales. Las personas que no sean técnicas no deberían nunca tocar el código del sitio web, después de todo, si no tienen idea de lo que están haciendo, ¡podrían romper algo accidentalmente!
Con respecto a la cuestión de la compatibilidad y la afirmación de que no se puede esperar que las personas no técnicas mantengan su propio servidor Apache, hay varias opciones que puedo ver. Una opción es que una persona administre la instalación de estos servidores para todas las partes involucradas, pero esto puede ser un trabajo de tiempo completo y es posible que su organización no se adapte a esa persona. La alternativa es usar una de las herramientas disponibles, como Vagrant o Docker, que permitirá a una persona técnica crear una "imagen" que tendrá el entorno de trabajo (que normalmente estará basado en Linux) y esa imagen se puede distribuir a todos desarrolladores para que puedan ejecutarlo en su propia máquina. Si es necesario realizar actualizaciones de la arquitectura, esta persona actualiza la imagen y la distribuye a los desarrolladores nuevamente.
Opinión personal:
De la publicación original deduzco que su compañía ha superado el estado de "solo 2 personas están trabajando en el sitio de todos modos, así que no importa lo que hagamos". Estos conceptos que propongo son ampliamente aceptados como buenas prácticas, como puede ver en mi explicación que obtendrá MUCHAS comprobaciones adicionales de la calidad del producto, en el momento de establecer una cierta complejidad adicional relativamente leve en su proceso. Un sistema de control de versiones como Git o Mercurial puede parecer intimidante, pero en mi opinión, con algo de entrenamiento, literalmente, cualquiera puede aprender a trabajar correctamente con él. Todo lo que requiere es una actitud de voluntad para aprender, en lugar de ver el sistema como un enemigo que le impide realizar su trabajo, el último de los cuales es, lamentablemente, mucho más común de lo que debería ser. Al aprender a usar la herramienta correctamente, se ahorra el tiempo que tendría que dedicar a corregir errores y al ordenar manualmente cómo se debe combinar el trabajo de varias personas en el código.