Best Practices to Develop / Buenas practicas de desarrollo

Events happening in the community are now at Drupal community events on www.drupal.org.
killua99's picture

Buenos días a todos/as.

He estado buscando un poco de documentación respecto a como implementar un estándar para el desarrollo de un sitio web creado obviamente con Drupal. Pero mis resultados no han sido muy buenos no he podido encontrar algo que me resulte de utilidad para un equipo de desarrollo de 3 ó + personas.

Mis puntos de mayor duda son de integración. Tengo bastante claro y es del uso común el SVN por parte de nuestro equipo de desarrollo, tenemos bien organizado el área de ficheros y sin ningún problema.

El problema que tenemos un poco es en el paso de integración de contenidos y base de datos que uno genere en local hacía integración.

Como serían los entornos de trabajo que se deberían usar en Drupal?

El entorno de desarrollo local de donde deberían estar tirando la base de datos?

El entorno de integración / test de que ficheros y base de datos deberían estar tirando también ?

El entorno de producción obviamente tiene que tener su base de datos aislada de la de desarrollo e integración así como los ficheros.

Como sería el flujo de trabajo un poco.

Solo pido 3 o 4 palabras de explicación tampoco una documentación super detallada. Sería genial si se han guiado de algún sitio que muestre como tienen configurado si área de desarrollo. Un link sería genial.

Muchas gracias.

Comments

Código hacia arriba, datos hacia abajo

jorgemaestre's picture

Hola,

Nosotros tenemos entornos de desarrollo similares al que comentas. Como norma general te diría que el flujo de código es hacia arriba, desde los equipos locales al SVN, y del SVN al entorno que corresponda. Por su parte, los datos irían desde la BBDD principal al resto de entornos y a los equipos locales.

Más en detalle, mantemos como BBDD principal la del entorno de producción, de la que generamos dumps periódicamente y bajo petición mediante un script. La copia generada se vuelva al SVN para que los desarrolladores tengan acceso a una copia actualizada. Esto mismo se hace con la BBDD del entorno de pruebas, de manera que estén disponibles versiones recientes de la BBDD de cada entorno.

En cuanto al código se preparan entregas (releases) para el entorno de pruebas y se etiquetan como tal. Una vez validadas se genera la correspondiente versión para el entorno de producción y también se etiqueta. La entrega la volcamos mediante rsync tras realizar un checkout de la versión adecuada.

Esta forma de funcionar obliga a realizar las configuraciones de módulos y demás, primero en el entorno local y después en los entornos de pruebas y producción, ya que los datos no van de "abajo a arriba". Para facilitar esta tarea, usamos una nomenclatura dentro de los comentarios del SVN donde se indica como hacerlo. También lo registramos dentro de nuestro gestor de proyectos en la tarea correspondiente.

Espero que te sirva de ayuda y animo a otras personas para que compartan su experiencia en el desarrollo drupal con equipos de varias personas.

Saludos.


Jorge Maestre

isaac.el.cec@gmail.com's picture

Hola...

Hay una descripción interesante de todo el proceso en el libro "Leveraging Drupal" de Victor Kane:
http://www.amazon.com/Leveraging-Drupal-Getting-Your-Right/dp/0470410876...

Saludos

Saludos
Isaac.el.Cec
- Temas DRUPAL: http://drupal6.propium.org
- Güep profesional: http://www.jramonet.org

Gracias por la documentación pero ...

killua99's picture

Muchas gracias a todos por este estilo de documentación y feedback.

Pero ahora con toda este estilo de documentación tengo un problema que se me esta dando (casi común) explico el caso para ver como sería una solución optima.

  • Existen dos personas de desarrollo.
  • Dos entorno de desarrollo local, lo que significa que tienen código fuente propio local (con SVN) y bases de datos locales.
  • En la puesta a integración/test tenemos los desarrolladores dos base de datos distintas, que integrar como content type, views, panels, configuraciones de roles y permisos, y otras cosas que quizás los módulos no tengan la opción de exportar e importar.

Ahí nos choca las bases de datos. La única solución que he encontrado es descartar una base de datos de un desarrolador, luego replicarla en test (porque aun la página no esta en producción) y después descargar un dump hacía el otro desarrollador. Luego cualquier alta de contenido configuración de permisos, roles, content types, panels, bloques, etc ... lo realizo en integración / test y luego realizo un dump hacía los desarrolladores.

Sería el orden que estoy llevando en el desarrollo. Ahora no se si es el correcto o existe otra forma mejor de realizar este proceso.

Gracias por todo el feedback.

[at]killua99 ~~

Modelo de desarrollo, testing, producción.

anieves's picture

Hola a todos, no se si es la forma correcta o la mas adecuada pero nosotros seguimos este proceso:

Todos los developers tienen su entorno con mismas versiones php y bdd mysql, trabajan y desarrollan en local (para evitar catástrofes que pudieran afectar al resto de developers), por supuesto con soporte svn que muy periódicamente commitean para actualizar el servidor svn central y algun que otro cron para hacer un dump de la bdd de localhost.

Existen 2 maquinas generales con el mismo entorno en ambas, exactamente igual que el entorno localhost de cada uno, cada día integran todos los contenidos exportables en la maquina1 destinada a desarrollo, todos en conjunto, si hay algún punto que no puede ser exportado directamente se implanta en la maquina1 y se bajan copia dump bdd de maquina1 a localhost, estando des actualizada siempre la bdd localhost o en algunos casos en la misma versión (para lo cual entonces no seria necesario hacer un dump de maquina1 -> localhost), todas las integraciones van al unisono, una vez se termina el desarrollo se pasa maquina1 a maquina2 en donde se hace testing, mientras se corrigen fallos o se cambian cosas en localhost -> maquina1 hasta finalmente solucionar incidencias detectadas en maquina2.

Es una escala hacia arriba con la salvedad de que todos y cada uno integramos las partes que desarrollamos en maquina1, siendo el ultimo proceso el dumpeo de maquina1 a maquina2 donde finalmente se ve por el cliente si testing no detecta ningún fallo funcional.

Espero que haya aportado alguna idea acerca de todo esto, en cualquier caso gracias por tu tiempo.

Saludos.

<?php
echo $signature
?>

Madrid

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: