Trabajo con otro desarrollador en un sitio de Drupal. Hemos luchado por encontrar una buena manera de trabajar en diferentes partes del sitio al mismo tiempo sin interponernos. Hemos intentado trabajar en la misma instancia de desarrollo del sitio, pero a menudo pisamos los pies del otro, o derribamos el sitio con algún código incorrecto que hace imposible que el otro continúe trabajando hasta que se resuelva. Así que nos hemos movido a instancias de desarrollo separadas. Pero ahora es un gran dolor fusionar nuestro trabajo en una sola instancia del sitio. Básicamente terminamos rehaciendo todo en una copia compartida.
El mayor problema que tenemos ahora es cómo fusionamos los cambios en la base de datos y cómo incluimos la base de datos en nuestro sistema de control de código fuente. Los archivos son fáciles, solo haga un seguimiento de todos (usamos git) y combine nuestro trabajo, resolviendo conflictos donde sea necesario. Pero esto realmente no funciona con la base de datos. Podemos hacer un volcado de SQL e incluirlo en nuestro repositorio de git, pero realmente no podemos fusionar las bases de datos. El módulo Características ayuda un poco, ya que nos permite exportar parte del trabajo de nuestra base de datos a un código que luego se puede versionar y fusionar. Sin embargo, ni siquiera cerca de todo es compatible con las características. Entonces...
¿Qué pasos podemos tomar para combinar fácilmente los cambios en nuestra base de datos?
¿Cómo deberíamos versionar la base de datos (poner un archivo de volcado en git es una buena manera de hacerlo)?
¿Hay algún módulo disponible que ayude con algunos de estos problemas?
¿O estamos atascados trabajando en la misma copia del sitio? (por favor así que no)
Editar: en los comentarios discutimos qué cosas no se pueden exportar con Características y una de ellas fue Taxonomías. Hay otra pregunta que se ocupa de eso .
Respuestas:
Es un cambio en el flujo de trabajo, pero debe acostumbrarse a trabajar en un nuevo volcado de la base de datos en vivo. Hay tres formas de obtener cambios en la base de datos.
Si puedes. Varias veces al día obtenga un nuevo volcado y pruebe su compilación, debería tener menos problemas de integración.
fuente
Respondí una pregunta similar y la voy a ajustar un poco para responder su pregunta aquí. Mi sugerencia raíz es que tiene un servidor de desarrollo / preparación donde los cambios de código se verifican utilizando un sistema de integración continua con frecuencia (por ejemplo, cada 5 minutos). Por lo tanto, en su máquina local, solo trabaja en una solicitud de función / informe de error a la vez, asegurándose de delinear claramente esta tarea de otras en las que las personas podrían estar trabajando y comunicándoles a sus compañeros de equipo que está trabajando en ella (redmine o otro seguimiento de errores es genial para esto). Luego, usted confirma los cambios de manera regular, y estos se despliegan en el servidor de desarrollo / preparación, al igual que sus compañeros de equipo. Idealmente, tiene pruebas unitarias integradas en su sistema de integración continua (por cierto, recomiendo luntbuild o QuickBuild para esto, pero Hudson también funciona). El sistema o las pruebas de CI pueden detectar automáticamente cualquier conflicto que pueda haber introducido tan pronto como ingrese su código. Si necesita realizar cambios en el contenido (sin código), hágalo en el servidor de desarrollo / preparación.
En cuanto a la parte de la base de datos, he adoptado básicamente dos escuelas de pensamiento aquí (una tercera escuela de pensamiento, haciendo diferencias en la base de datos, no lo discutiré porque la complejidad es bastante alta).
1) Implemente soltando la base de datos de producción e importando un mysqldump de la base de datos de desarrollo. Opcionalmente, ejecute una búsqueda / reemplazo de expresiones regulares de antemano en cualquier enlace absoluto codificado que haga referencia a la URL del desarrollador en el volcado de SQL. Después de importar el dev db en prod, ejecute automáticamente sentencias SQL (generalmente a través de script) para cambiar cualquier configuración que sea diferente para prod que para dev (por ejemplo, tal vez tenga en la tabla de variables algunas configuraciones de conexión para conectarse a sistemas externos que necesita cambie para apuntar a sistemas externos prod en lugar de a la versión de desarrollo).
2) Use el módulo Características, como lo menciona budda, para la configuración de administración, y use el módulo Exportar nodo para la exportación / importación de contenido en combinación con el módulo Eliminar todo. Entonces el flujo de trabajo es:
use node_export y características para exportar nodos / características a archivos Opcionalmente (y con suerte) control de versiones Cargue archivos en el sistema prod Use drush o interfaz de administrador para cargar características Use drush delete-all o interfaz de administrador para eliminar todos los nodos del tipo que desea importar Utilice drush ne-import o la interfaz de administración para importar los nodos del archivo de nodos que exportó. Una nota, sugeriría adoptar un flujo de trabajo estándar, donde el contenido va solo en una dirección. O Dev -> Prod o Prod -> Dev (prefiero este).
He hecho esto, y lo estoy haciendo en algunos sistemas grandes, con resultados bastante buenos, pero siempre habrá muchas maneras de cortar esta manzana, elija la que mejor funcione para usted.
fuente
Si bien esta es una vieja pregunta con una respuesta aceptada, creo que todavía hay espacio para otra.
Primero, permítanme decir por adelantado que no creo que Características sea la herramienta adecuada para esta tarea, y propondré un conjunto alternativo de herramientas.
Un requisito previo para la colaboración del equipo es tener un servidor de ensayo para probar las versiones de desarrollo del proyecto que es independiente de su servidor de producción. Todo el código de desarrollo se prueba en el servidor intermedio y solo se envía al servidor de producción cuando es estable y está listo para la implementación. Sin embargo, los desarrolladores no trabajan directamente en el servidor de ensayo. Cada desarrollador trabaja en su propia estación de trabajo, utilizando un control de revisión y gestión de código fuente (SCM) para coordinar su trabajo con el resto del equipo.
El sistema SCM permite a los miembros del equipo trabajar en paralelo en diferentes ramas del código sin interferir entre sí. Solo la rama maestra se implementa en el servidor de ensayo con fines de prueba.
Para reflejar la base de datos entre la producción, la preparación y las estaciones de trabajo, hay un módulo llamado Copia de seguridad y migración que puede usarse si se encuentra en un alojamiento compartido y no administra su propia base de datos. Si está administrando su propio servidor de base de datos, este es el único proyecto en ese servidor, y usa mysql , el siguiente par de comandos son útiles:
Para volcar:
Restaurar:
Si la suya no es la única base de datos en ese servidor, cree una versión de script
mysqldump(o equivalente si no está usando mysql ) que solo descarga sus bases de datos.Haga una política de que es la base de datos en el servidor de producción la que es maestra. El servidor de ensayo y las estaciones de trabajo deben ser una copia de la base de datos de producción, no viceversa.
Tenga en cuenta que Drupal 7 mantiene toda su configuración de administrador en la base de datos. Esto significa que duplicar la base de datos entre el sitio de producción, el sitio de preparación y las estaciones de trabajo migrará la configuración de admiración sin características .
Ahora, para compartir el código:
La forma estándar de compartir código entre los miembros de un equipo de desarrollo es usar el sistema SCM. Drupal pasa a ser predeterminado administrarse con un sistema llamado git .
Git permite el uso de repositorios locales o remotos. Si los miembros del equipo se encuentran en el mismo espacio físico, puede configurar un repositorio local en su servidor de ensayo. Si se extienden geográficamente, puede configurar un repositorio remoto. Si no le importa que otros tengan acceso de lectura a su código en desarrollo, puede usar un sandbox en Drupal.org como repositorio remoto. También puede usar un área de proyecto en GitHub . GitHub no es solo un repositorio, sino que viene con algunas herramientas para la colaboración y permite tanto repositorios públicos como privados.
Básicamente, un sistema SCM permite a los miembros del equipo extraer el código fuente y la documentación del repositorio compartido por los miembros del equipo, y volver a introducirlo después de haber trabajado en él. El SCM realiza un seguimiento de los cambios y, si hay un conflicto (es decir, alguien intenta introducir un código que no contiene los cambios que otro miembro del equipo ha cometido), le informará y también le sugerirá una forma de resolver este conflicto.
Por lo general, con una comunicación cordial sobre cómo se dividen las tareas entre los miembros del equipo, no habrá conflictos. Pero con el sistema SCM haciendo un seguimiento de las cosas, los conflictos se vuelven manejables incluso si se cometen errores o falla la comunicación.
Existen muchos tutoriales sobre cómo comenzar a usar git (GIYF). Dos que recomendaré son: el sitio web git-scm y Pro Git de Scott Chacon.
fuente