Entorno de desarrollo con múltiples desarrolladores en una sola aplicación

Estoy buscando una buena manera de optimizar / mejorar la forma en que mis colegas y yo trabajamos en nuestras aplicaciones.

Actualmente, todos trabajamos en PhpStorm en una MacBook Pro (2016), un server de Ubuntu en nuestra networking y una copy de trabajo mapeada en SMB para nuestras máquinas (a veces editamos los mismos files, lo que lo hace inconveniente). Usamos Git como control de origen y tenemos 1 twig en la que todos trabajamos.

Estamos notando problemas de performance al utilizar PhpStorm en el recurso compartido de networking, nuestra aplicación es bastante grande y tener el índice PhpStorm todo lo congela y no responde todo el time.

Estamos buscando una manera de mejorar la forma en que trabajamos, simplificando el desarrollo de nuestra aplicación y eliminando los problemas de performance que tenemos con la combinación de networking compartida / copy de trabajo.

Estamos pensando en tener una copy de trabajo localmente en nuestras máquinas, tener un server web virtualizado (Vagrant) y ejecutar la aplicación por separado el uno del otro. Esto solucionaría los problemas con la networking, sin embargo, traería otros problemas, si yo, por ejemplo, hago cambios en la database, estos cambios también tendrían que hacerse en la copy de trabajo de mi colega.

Además, realizamos cambios en los mismos files todo el time, lo último que queremos es solucionar conflictos de files cada vez que hacemos cambios, sin embargo tener que extraer cada confirmación que otro desarrollador realiza durante el día, además de tener que hacer sus cambios en la database manualmente.

TL; DR, ¿cuál es una buena forma de trabajar en 1 aplicación con 3 desarrolladores?

https://www.atlassian.com/git/tutorials/comparing-workflows

Preste atención a la parte donde dice: "Los desarrolladores comienzan clonando el repository central. En sus propias copys locales del proyecto, editan files y comprometen los cambios como lo harían con SVN, sin embargo, estos nuevos compromisos se almacenan localmente, ellos ' Está completamente aislado del repository central, lo que permite a los desarrolladores diferir la synchronization aguas arriba hasta que estén en un punto de interrupción conveniente ".

Una vez que tienes esta idea, el rest sigue, creo.

  1. Siempre actualice su sucursal local desde el maestro y la testing antes de registrarse
  2. ¡Regístrese a menudo! Múltiples veces al día. Vea el punto 1. ¡Cada checkin debe contener el código relevante y el código de script SQL (y cualquier otro recurso), y debe comstackr y trabajar!
  3. Los conflictos de fusión ocurrirán. NO hay varita mágica, o estrategia. En general, intente coordinarse para que los desarrolladores generalmente trabajen en áreas aisladas (esto presupone que su código está estructurado muy bien para hacerlo. Lo cual es generalmente una buena idea, pero un tema demasiado grande para aquí). Aconsejo mantener cambios en un file con cualquier código que se genere automáticamente a un desarrollador por vez. (¡esto es experiencia!).
  4. Todos los cambios de la database deben ser un script y, por lo tanto, un file de código, manejado de la misma manera que todos los otros códigos en términos de control de versiones, los desarrolladores deben probar en su propia copy local de la database antes de comprometerse. Probablemente necesites que alguien supervise los guiones antes del lanzamiento, para search conflictos. Puede tener una regla de que hay un file de script por object de database (tabla, vista, sp), ¡lo hace más fácil!

Una buena mejora definitivamente estaría trabajando en su propia copy local de la aplicación. Como usted describe, esto solucionaría los problemas de performance, pero le dará problemas relacionados con las actualizaciones de la database.

Una forma de administrar las actualizaciones de bases de datos es hacer uso de los files de migration para cada cambio de esquema de database. Digamos que haces un cambio, agregas este cambio a un nuevo file de migration que agregas al repository de git. Al tener esos files, todos pueden aplicar todas las migraciones en la parte superior de su database de desarrollo local para mantener su database actualizada. También hace que las testings sean muy fáciles porque puede restablecer su database en cualquier momento y aplicar las migraciones nuevamente.

Puede echar un vistazo a cómo otros aplican esto. Hay frameworks de back-end que soportan esto de la caja (por ejemplo, Laravel para PHP).

Una solución que puedo pensar podría ser usar un sistema de control de versiones como git. Me parece que quiere que todos estén trabajando en el mismo proyecto y posiblemente la misma característica al mismo time.

Para minimizar los conflictos de fusión, sugiero crear una twig de desarrollo y para cada característica debe ramificarse de la twig de desarrollo y estar aislada hasta que haya una actualización (alguien se haya fusionado o haya terminado con la característica y se haya fusionado). Los otros desarrolladores pueden hacer esos cambios desde dev y continuar en su function.

Si el problema se basa en el entorno, puede usar la function de acoplador en ides de JetBrains para crear un entorno común en el que trabajar.

Después de haber agregado un comentario a la respuesta original, creo que debe proporcionarse como respuesta:

  • Use git correctamente como una herramienta de control de versiones. Al hacer que todos los desarrolladores trabajen en un único recurso, definitivamente no se está aprovechando de qué se trata el control de la versión. Haga que cada desarrollador trabaje en sus propios treees de trabajo (localmente o en un server si desea mantenerlo así) para que puedan aprovechar las características de git para el desarrollo local (crear sus propias sucursales, operaciones rápidas, no meterse con lo que otros la gente está haciendo) y luego fusionar cosas juntas en las twigs superiores de desarrollo cuando las cosas están lists. Esto debería encargarse de muchos de tus problemas.

Esa es la máxima prioridad en mi list.

Si bien personalmente preferiría usar Git y sus sucursales, la function de implementación de PhpStorm podría ser una solución para usted. Entonces, en lugar de usar un recurso compartido en networking, puede tener una copy local que se actualizará desde el recurso externo. Aquí están el tutorial de configuration y el tutorial sobre cómo mantenerlo actualizado automáticamente.

Debe almacenar sus repositorys GIT en una location centralizada, por ejemplo, en Github o en uno de sus serveres locales. Cualquier desarrollador podría extraer / enviar los cambios desde / hacia el repository central y trabajar con copy local (sin networkinges SMB).

Considere usar contenedores Docker. Esto permitiría tener todos los mismos entornos de desarrollo exactamente.

Los cambios en la database podrían hacerse usando migraciones de bases de datos. Ver esta biblioteca doctrine / migrations .