¿Alternativa a la codificación directamente en el servidor? [duplicar]

12

Tenemos un gran sitio web hecho en PHP que se ejecuta en Apache en Linux. Hay programadores y usuarios no técnicos que modifican el sitio web todos los días y lo hacemos directamente en el servidor de prueba.

¿Existe alguna alternativa para modificar los archivos directamente en el servidor?

Claro, todos los programadores pueden configurar una instancia de Apache en su máquina y administrarla, pero es un problema ya que a veces agregamos una nueva extensión a PHP o cambiamos la configuración en Apache, lo que significa que todos deben cambiar esas cosas manualmente. Además, no es realista esperar que nuestros usuarios no técnicos administren su propia instancia de Apache.

Otro problema es que todos estamos en una computadora con Windows, pero el sitio web se ejecuta bajo Linux. El código no es compatible con Windows, por lo que es otro problema. Cambiar por completo a Linux no es una opción, ya que estamos utilizando muchos programas que solo se ejecutan en Windows para otras tareas, por lo que tendría que ser un arranque dual o una máquina virtual.

Se siente extraño que todo el trabajo se realice directamente en el servidor, pero ¿es la mejor manera de hacerlo en nuestro caso?

    
pregunta Gudradain 05.11.2015 - 23:53

5 respuestas

54

Todos los que modifiquen la aplicación deben hacerlo en el control de origen, y debe tener un proceso automatizado para implementar una versión específica del control de origen en su servidor de prueba. Puede requerir cierta persuasión para que su personal no técnico use el control de código fuente, pero realmente no es una alternativa para mantener un sistema de no-juguete funcionando de manera confiable. Si el paso para registrar e implementar el código es lo suficientemente simple, no importará que nadie trabaje directamente en el servidor. A la gente le gusta usar git para esto porque git es rápido y ha desarrollado un ecosistema de buenas herramientas para el usuario final. Hacer que las personas trabajen directamente en el servidor es una receta para el desastre.

    
respondido por el antlersoft 06.11.2015 - 00:02
19

Use vagrant para configurar el entorno que refleje la configuración en el servidor y deje que jueguen allí.

Cómo devolver las cosas al servidor, se trata de la implementación, esa parte está bien respondida por @antlersoft, con la advertencia: no creo que pueda persuadir a los usuarios no técnicos para que utilicen el control de código fuente (y git es uno de los más duros). Si necesita usuarios no técnicos para cambiar la web, invierta tiempo y dinero para encontrar el CMS adecuado y úselo.

    
respondido por el herby 06.11.2015 - 00:08
11

Una flota de máquinas virtuales en un host, cada usuario tiene su propia instancia para jugar, luego, desde allí, al repositorio principal y realiza la actualización del servidor de prueba real desde allí.

No intentes introducir git a usuarios no técnicos, podrías terminar con un hacha en tu cabeza un día. :-) Incluso para potenciar a los desarrolladores que lo usan todos los días, agrega un nivel tan alto de complejidad que fallan. Las herramientas como SourceTree son agradables, pero aún así no lo protegen contra errores.

El control de versión más fácil de usar que he experimentado hasta ahora es TortoiseSVN, incluso los usuarios no técnicos entienden los comandos svn up y svn commit cuando se presentan en una interfaz gráfica limpia.

    
respondido por el user203035 06.11.2015 - 03:52
10

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.

    
respondido por el Cronax 06.11.2015 - 12:21
3

En primer lugar, el control de versiones es un deber. Pero además, cualquier cambio debe probarse antes de comprometerse. Y para esos cambios, cada usuario necesita su propio entorno de prueba. Por lo tanto, codificar directamente en el servidor no es una buena idea.

La cantidad de separación que necesita entre el entorno de prueba de cada usuario depende de sus necesidades específicas. Para algunas tareas simples, puede lograr una separación suficiente al tener un servidor de prueba compartido ejecutando un host virtual por usuario. Si necesita más separación, puede configurar un VPS por usuario.

Para las tareas más exigentes, es posible que necesite una máquina física dedicada por usuario. Si eso significa que necesita comprar otra máquina física para algunos usuarios, debe decidir si desea que la otra máquina esté ubicada en el escritorio del usuario o en un servidor en rack.

He visto a usuarios cometer errores en todos los sistemas de control de versiones con los que he trabajado. Algunas personas pueden aprender a trabajar correctamente con un sistema de control de versiones, otras no. Si tiene personas no técnicas que necesitan cambiar parte del código base, pero no pueden aprender a usar el control de versiones, hay otra opción que vale la pena considerar.

Puede permitir que los desarrolladores tengan acceso a las máquinas de prueba de la persona no técnica (ya sea como inicio de sesión de shell o a través de un sistema de archivos de red), de modo que una vez que el cambio esté listo, la persona no técnica puede pedirle a un desarrollador que se comprometa el cambio.

    
respondido por el kasperd 06.11.2015 - 13:19

Lea otras preguntas en las etiquetas