¿Cuáles son las mejores prácticas para un pequeño equipo distribuido que trabajará en un proyecto de Drupal?

Question

después de algunas investigaciones, optamos por trabajar con Drupal en nuestro próximo proyecto y somos un equipo distribuido.

Desde las tiendas Drupal (en base a lo que vimos hasta ahora) todo su contenido en una base de datos, ¿cómo podemos, como un equipo distribuido, trabajar juntos en este proyecto? ¿Cuáles son las mejores prácticas que debemos tomar?

Pensamos utilizar un servidor de base de datos compartido para esta tarea, pero simplemente destruiría el rendimiento que deberíamos necesitar para poner en marcha este proyecto. Alguna sugerencia sobre eso?

Answer 1

La respuesta de Jeremy (+1) ya es bastante completa. Algunos consejos adicionales más orientados a la práctica siguen en sin pedido particular.

Descargo de responsabilidad: esto es lo que funciona para mí. Otros pueden tener otra sugerencia o incluso estar en desacuerdo. ¡Si este es el caso, me sentiría súper feliz de escuchar los comentarios y las propuestas alternativas/mejores!

1. hacer un punto que cada miembro del equipo debe comenzar su/su sesión mediante la actualización del código y la base de datos. Puede escribir fácilmente todo eso con una combinación de comandos ssh y rsync. A veces creo un único script (update-project.sh) que actualiza el código del repositorio y descarga e importa el último DB desde el servidor maestro a la vez.

2. Nunca olvide llamar al http://example.com/update.php cada vez que actualice el código. Ejecute este comando en su sitio de ensayo, después de cada confirmación, y en su máquina local después de cada actualización/extracción/pago.

3. Haga cualquier cambio al DB mediante consulta SQL, en lugar de con una GUI. De esta forma, simplemente tendrá que ajustar esa consulta en una implementación hook_update_N() en su archivo yourmodule.install, y estará a salvo (si cumple con el punto 2) [alguna herramienta GUI genera el equivalente ... ¡eso también es práctico!].

4. Siempre que sea posible, incluir en hook_update_N() cambios también a la configuración del módulo. Esto no es posible todo el tiempo. Cuando no es posible: vea el punto # 7 y # 8.

5. Al crear o modificar una vista, exportarlo a un archivo cuando haya terminado. Mismo principio que el punto n. ° 3 aplicado a las vistas. Este enfoque también tiene el beneficio de proporcionar un mecanismo de reversión en caso de que luego se dé cuenta de que cometió un error.

6. Utilice un repositorio principal. No opte por un sistema de control de versiones demasiado distribuido. Tire y presione su código siempre desde el mismo repositorio central.

7. Siempre incluya un comentario en la confirmación. Especialmente si algún cambio de código cambia alguna funcionalidad/API/lógica común, asegúrese de incluir una advertencia en su mensaje de confirmación. La información detallada se puede poner en un archivo changelog.txt, si es necesario.

8. Al comprometerse, reproduzca inmediatamente en el DB maestro cualquier cambio de base de datos hecho a mano que no haya logrado incluir en su implementación hook_update_N(). Esto es obligatorio si los miembros de su equipo comienzan sus sesiones como se describe en el n. ° 1.

9. Sea selectivo en lo que pone en las versiones. Por ejemplo: excluya el sites/default/settings.php pero evalúe qué (si hay algo) necesita versionar en sites/default/files (¿se necesitan imágenes para el desarrollo? Y archivos adjuntos?).

10. Hay algunos módulos útiles que pueden ayudar. Me gusta import/export, que le permite administrar en un repositorio su CCK y Vistas o node export que le permite exportar nodos y luego importarlos en otra instalación de drupal.

11. Utilice ampliamente el simpletest module. Esa es una buena idea de todos modos, pero cuando se trabaja en equipo es una gran idea : de esa manera usted estará seguro de que sus cambios no han roto el trabajo de nadie más.

12. Have fun! Me encanta trabajar en equipo y creo que uno debe intentar hacerlo cada vez que pueda. Es más divertido, más aprendizaje y, sobre todo ... ¡mejor código!:)

punto de bonificación (no se refiere al desarrollo del equipo en concreto):

• trate de no usar el servidor de transición para la inserción de contenido real. Idealmente, debería comenzar a crear contenido solo cuando el código esté congelado o usar un enrutamiento/módulo de importación: drupal dispersa información entre tablas mucho, y el sistema de enganches hace muy difícil rastrear qué módulos almacenaron qué información: si desarrolle en una base de datos con datos reales, inevitablemente terminará rompiendo algunas tablas en algún momento, y tal vez se dé cuenta de eso solo un día antes de entrar en producción. :(

Answer 2

En primer lugar, las mejores prácticas.

Siempre debe considerar su base de datos en vivo el maestro. Puede usar los volcados de la base de datos para obtener esta base de datos en vivo de cada miembro de su equipo distribuido. Esto asegura que cada miembro del equipo trabaje desde la misma base.

Debe utilizar un sistema de control de versiones para compartir su código, para que todos trabajen desde la misma base de código, pero tengan control sobre cuándo fusionar el código.

Compartir una base de datos entre desarrolladores, o compartir una base de código entre desarrolladores causará confusión y debe evitarse.

pensamientos basa ahora un poco más de opinión

contenido para su sitio deben ser creados y editados en el servidor en vivo.

Debe liberar el código de forma administrada y repetible. Lo ideal sería tener un servidor de prueba para probar el código antes de que se active.

La parte engañosa es el contenido y los cambios de configuración. He defendido que esto debería hacerse en funciones de actualización en un módulo ficticio. Sin embargo, a veces esto es difícil de hacer, o en algunos casos los cambios no se pueden hacer de manera confiable. Entonces debería haber un equilibrio, la mayoría de los cambios de configuración deberían hacerse en código, por lo que son repetibles y se pueden distribuir fácilmente entre los desarrolladores. Pero para los cambios de configuración que no se codifican fácilmente o que se requieren fuera de una ventana de lanzamiento, puede hacerlos directamente en el servidor activo. Lo importante es que puede obtener su código y base de datos en un estado coherente a través del desarrollo y en vivo.

Answer 3

Simpletest es una herramienta muy valiosa ya que un desarrollador que está trabajando en el módulo "A" puede ejecutar el conjunto de pruebas y asegurarse de que no ha roto el módulo "B" y comprometido (por ejemplo). el módulo Simpletest y Selenium IDE. El desarrollo impulsado por pruebas rinde más de una. Los desarrolladores ganan confianza y pueden trabajar más rápido/mejor

Un buen software de gestión de proyectos y/o seguimiento de problemas puede mantener toda la información del proyecto centralizada y facilitar la comunicación entre desarrolladores. Un wiki también es bueno. Los correos electrónicos entre los administradores de proyectos y los desarrolladores individuales no mantienen a todos al tanto y pueden perderse en el tiempo, en un entorno de correo electrónico ruidoso.

Me gustan las salas de chat de desarrolladores para proyectos distribuidos. Chatear en tiempo real es muy útil. Algunos controles de versiones pueden escribir mensajes de confirmación en las salas de chat.

El módulo backup_migrate es útil para tomar el último accesorio DB fuera del servidor de producción. Por supuesto, puede exportar a través de mysqldump, etc., pero este pequeño módulo es pan comido.

Echa un vistazo a doxygen también. Fuerza a tus desarrolladores a escribir en ese formato. Y preste atención a los estándares de codificación drupal. Hay un módulo llamado "codificador" que puede verificarlo.

Answer 4

Veo que esta es una publicación ANTIGUA con respecto a la administración de configuración de Drupal. Por ahora, en 2013, definitivamente recomendaré completar el módulo de funciones. Esto le permite colocar la configuración en el código y usar el control de versión (recomiendo git) para pasar los archivos a través de sus entornos. Hay algunas advertencias pero funciona en su mayor parte. Para las advertencias, el uso de los consejos mencionados en la respuesta aceptada ayudará a mitigar la confusión