Administre el control de versiones con un servidor de desarrollo central (LAMP)

Estoy trabajando en un pequeño equipo con hasta 5 desarrolladores (web). Debido a que nuestro equipo está creciendo con frecuencia y tuvimos problemas con varias personas trabajando en el mismo código, decidimos configurar un VCS.

Situación actual

Actualmente estamos trabajando con un servidor de desarrollo central (LAMP). Por lo tanto, cada desarrollador trabaja en la misma base de código y si el código está probado y listo para nuestro servidor en vivo, simplemente lo copiamos a través de ftp. Sé que esto es una especie de flujo de trabajo anno 1600, pero sí, es lo que es y también la razón de esta pregunta.

En el servidor de desarrollo, nuestra estructura de directorios se ve así:

/var/www 
      /Project1 
      /Project2 
      /Project3 
      ...

Además, hay algunas aplicaciones pequeñas que no son aplicaciones web: aplicaciones de Android / iPhone / Windows 8, etc. y algunas herramientas de C # que también deben incluirse en el VCS.

Meta y problemas

Nuestro objetivo es obtener una configuración limpia para un VCS, que funciona junto con un software de seguimiento de problemas, nos permite trabajar juntos en el mismo proyecto al mismo tiempo sin sobrescribir nuestros códigos y simplemente nos da la ventaja del control de versiones.

Creo que la primera pregunta para nosotros es qué tecnología deberíamos usar. Algunos de nosotros ya hemos experimentado la subversión. Pero debido a que git se está convirtiendo en el "estándar" y hay muchos argumentos "pro git" entre los usuarios de la web, tendemos a usar git.

Ahí comienza nuestra incertidumbre. Para usar git, un VCS descentralizado, parece que tenemos que comenzar a usar servidores de desarrollo separados en la computadora de cada desarrollador. Los problemas con eso son:

• Algunas veces trabajamos en diferentes computadoras, así que cuando nos olvidamos de presionar nuestro código tenemos un problema.
• Tendríamos que trabajar con máquinas virtuales porque los servidores de desarrollo deberían ser los mismos que nuestro servidor en vivo (Esto simplemente no sería exigible en nuestro entorno, créanme que no es posible).
• El servidor de desarrollo generalmente también servía como un servidor de "prueba" o "presentación" donde los no desarrolladores tenían un vistazo de lo que estaba sucediendo.

¿Hay otra configuración posible con git para que podamos beneficiarnos del sistema mientras todavía usamos un solo (!) Servidor de desarrollo? Quizás con diferentes directorios para cada desarrollador. ¿O podemos seguir trabajando en la misma base de código tal vez bloqueando los archivos en los que estamos trabajando y luego enviarlos a un repositorio? Quizás sea importante decir que, si bien se convirtió en un factor para nosotros, todavía es poco común que varios desarrolladores trabajen en la misma parte de una aplicación al mismo tiempo.

Estás en el camino correcto, aquí.

Quizás con diferentes directorios para cada desarrollador.

Sí, definitivamente directorios diferentes para cada desarrollador.

La máquina en la que estás es bastante poco interesante. Solo asegúrese de que cada desarrollador inicie sesión como él mismo y obtenga una copia del repositorio de git en su propio directorio de inicio. Terminará con varias copias del código que vive en su sistema de archivos, pero bueno, el disco está libre.

Es cierto que git admite operaciones descentralizadas. Pero no lo usará de esa manera en su flujo de trabajo típico. Solo asegúrate de que haya un repositorio disponible en algún servidor conveniente y haz que todos tomen eso. Acceda a través de http, ssh o incluso a través del sistema de archivos si lo desea.

Usted mencionó un área de "prueba" como parte de su flujo de trabajo. Hazte un favor. Contrata a otro desarrollador, llamado Jenkins, que también revisa tu código usando git. Se implementa aquí: http://jenkins-ci.org/ (y se ejecuta en http://tomcat.apache.org/download-70.cgi ). De esa forma, cada vez que se ingrese al repositorio central, una versión actualizada de su sitio web estará disponible en el directorio de inicio de Jenkins, donde podrá probarlo rápidamente y ejecutar controles de sanidad. A esto le llamamos integración continua, y definitivamente mejorará su flujo de trabajo.

 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

Si pocas personas trabajan en la misma máquina y la misma base de código, las cosas tienen que salir mal. Por sobrescribir y porque si uno rompe algo, otros tienen que esperar hasta que se arreglen para probar sus cosas.

Necesita distinguir pocos entornos. Parece que necesitas tres (muy común):

• Producción : donde el proyecto es realmente utilizado por los usuarios finales.
• Puesta en escena : lugar donde el desarrollador fusiona su trabajo con otros desarrolladores, lo prueba y, a veces, los clientes pueden echar un vistazo a esta área.
• Desarrollo : donde cada desarrollador trabaja solo, antes de fusionarse con otros.

Por lo general, el entorno de desarrollo significa que el desarrollador de la máquina trabaja. Si desea mantenerlo en una máquina compartida, también puede hacerlo. Ambientes y máquinas es algo desacoplado. Solo necesita tener una base de código diferente para cada proyecto, cada desarrollador y cada entorno.

Entonces, en el caso de Git y 5 desarrolladores en la compañía, habría 5 repositorios para el entorno de desarrollo . Para el entorno de ensayo (código de fusión) porque no es una buena idea utilizar repositorios no vacíos, necesitaría un repositorio para fusionar y otro para probar el código allí y mostrar el estado actual del cliente. Si el servidor de producción tiene Git, hay otro allí. Si no, simplemente transferiría archivos a producción a través de FTP desde el entorno de ensayo Tan pocos repositorios para cada proyecto.

Y el flujo de trabajo es así: obra que en su desarrollo medio ambiente, al añadir una característica o arregló un fallo empujar los cambios en la organización de entorno de recompra desnudo y tirar de esto fuera en el desnudo no (un gancho Git podría hacer eso a la vez) , y cuando el proyecto está listo para lanzar una nueva versión, lo empuja (o transfiere a través de FTP) a la producción .

Algunas veces trabajamos en diferentes computadoras, así que cuando nos olvidamos de presionar nuestro código tenemos un problema.

Bueno, si tiene que hacer un entorno de desarrollo en el mismo servidor compartido, puede sincronizar sus archivos de la máquina local al servidor a través de algo como rsync, o asignar una unidad de red o lo que sea, pero esto siempre será un poco más lento que trabajar en una máquina local . Sin embargo, trabajar localmente tiene el problema que mencionas. Incluso sin VCS. Al igual que cuando usa FTP, si cambia algo en su máquina y olvida transferirlo, sucede lo mismo. Pero no querrá fusionar su código desensamblado con el entorno de ensayo seguro. Tiene que permanecer en desarrollo hasta que alcance un estado razonable.

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

Los servidores wev sin GUI no usan muchos recursos. Creo que ustedes podrían trabajar en el código y probarlo todos en su propia máquina. Por lo tanto el desarrollo entorno necesitas cigarros, y sólo puesta en escena en el servidor compartido. Puede consultar algo como Vagrant para ayudar a administrar imágenes de máquinas virtuales. Por lo tanto, asegúrese de que cada proyecto tenga la configuración correcta. Esto garantizaría que ustedes prueben de la misma manera, estén más seguros (ahora si el servidor compartido se rompe, nadie puede continuar trabajando, y necesita tener una buena copia de seguridad allí) y más rápido (no se necesita transferencia hasta la fusión). Git es mejor diez SVN en este asunto porque mantiene un repositorio completo en cada máquina con historial y todo, por lo que si una PC se rompe, todavía hay buenas copias en otro lugar.

También cosas como la Gitosis pueden ayudarlo a administrar la configuración de repositorio del entorno de ensayo , y Redmine u otro software de administración de proyectos a menudo tiene formas de integrarse con VCS.

porque git se está convirtiendo en el "estándar" y hay muchas personas "pro git" entre los usuarios de la web que tendemos a usar git.

Esta es una base pobre para elegir en SCM-world. Git no es "estándar", sino más bien "moda" con mucho ruido a su alrededor. "Pro Git" es más fanboyismo que una decisión sensata y razonada en muchos casos

trabajar juntos en el mismo proyecto al mismo tiempo sin sobrescribir nuestros códigos y simplemente nos da la ventaja del control de versiones

Las ramas en cualquier SCM le permitirán obtenerlo, incluso con Git (palabra clave: "Git-flow")