2008-11-12 19 views
32

En proyectos estándar basados ​​en php o en código fuente, conservamos fácilmente todo el código en SVN y cada desarrollador puede verificar su propia copia y colaborar en el mismo código.Drupal Source Control Strategy?

Al desarrollar un sitio Drupal, sin embargo, gran parte del trabajo está en "configuración". Además del tema y los módulos, realmente no tienes ningún "código fuente". ¿Cómo se ejecutan varias instancias del mismo sitio para que los desarrolladores puedan trabajar al mismo tiempo y compartir su trabajo?

Escenario de ejemplo:

Lanzamos una versión inicial de un sitio Drupal con el tipo de contenido "X" creado. También lanzamos inicialmente una vista en el sitio que enumera todos los nodos del tipo "X" en orden cronológico. El cliente comienza a usar el sitio, agrega contenido, elementos de menú, etc.

El próximo lanzamiento se planea para agregar la capacidad de búsqueda del usuario a esa vista. La configuración para eso está contenida en la base de datos sin embargo. Podemos copiar la base de datos de producción a nuestra versión de desarrollo para obtener los últimos datos mientras trabajamos en cambiar la vista. Durante ese tiempo, sin embargo, el cliente aún puede estar actualizando el sitio, lo que hace que nuestra base de datos dev no esté sincronizada. Cuando estamos listos para impulsar la nueva vista hacia la producción, ¿hay una manera más fácil de hacerlo que no sea repetir los pasos manualmente para configurarla en la instalación de producción?

+0

hmm ¿Puedes aclarar un poco? ¿Estás hablando de configuración como la configuración en ciertos módulos, básicamente? – Owen

+0

muy buena pregunta, gracias. – sepehr

Respuesta

11

Creo que una buena estrategia aquí es usar la API de perfil de instalación. Con la API de perfil de instalación puedes hacer la mayoría de las cosas que hacen las herramientas de administración de Drupal. La mayoría de las formas básicas simplemente configuran variables en la tabla de variables. Para poder realizar una versión sensata de los contenidos de su base de datos no contenida, es decirconfiguración, es aconsejable usar las funciones de actualización.

En mi sitio tenemos el módulo "ec" que hace muy poco aparte de tener su archivo ec.install que contiene funciones de actualización, p. ec_update_6001()

Su función de instalación principal puede encargarse de ejecutar realmente las actualizaciones en cualquier instalación nueva que realice para actualizar sus módulos.

function ec_install() { 
    $ret = array(); 
    $num = 0; 
    while (1) { 
    $version = 6000 + $num; 
    $funcname = 'ec_update_' . $version; 
    if (function_exists($funcname)) { 
    $ret[] = $funcname(); 
    $num++; 
    } else { 
    break; 
    } 
    } 
return $ret; 
} 

una función de actualización de la muestra o dos de nuestro archivo real ahora siguen

// Create editor role and set permissions for comment module 
function ec_update_6000() { 
    install_include(array('user')); 
    $editor_rid = install_add_role('editor'); 
    install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments')); 
    install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval')); 
    install_add_permissions($editor_rid, array('administer comments', 'administer nodes')); 
    return array(); 
} 
// Enable the pirc theme. 
function ec_update_6001() { 
    install_include(array('system')); 
    // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789. 
    install_enable_theme('pirc'); 
    return array(); 
} 

// Add the content types for article and mtblog 
function ec_update_6002() { 
    install_include(array('node')); 
    $props = array(
    'description' => 'Historical Movable Type blog entries', 
); 
    install_create_content_type('mtblog', 'MT Blog entry', $props); 
    $props = array(
    'description' => 'Article', 
); 
install_create_content_type('article', 'Article', $props); 
return array(); 
} 

Efectivamente, esto resuelve el problema la mayoría de versiones con bases de datos y código de Drupal. Lo usamos ampliamente Nos permite promocionar un nuevo código que cambia la configuración de la base de datos sin tener que volver a importar la base de datos o realizar cambios en vivo. Esto también significa que podemos probar adecuadamente las versiones sin temor a cambios ocultos en la base de datos.

Finalmente, cck y views admiten este enfoque. Ver este fragmento de código

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration, 
// enable body for article, enable migration modules. 
function ec_update_6023() { 
    $ret = array(); 
    drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets')); 
    install_include(array('content', 'content_copy')); 
    install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article'); 
    $sql = "UPDATE {node_type} SET body_label='Body', has_body=1 
    WHERE type = 'article'"; 
    $ret[] = update_sql($sql); 
    return $ret; 
} 
11

Escribí un artículo sobre painless Drupal revision control with CVS and Subversion mejores prácticas hace un tiempo.

Lamentablemente, todavía existe la cuestión de que la fuente controle la base de datos, como ha señalado. Hay algunos métodos sugeridos, que menciono en un additional post.

+0

Los enlaces están muertos, y ni siquiera puedo encontrar una versión en caché de google de la segunda (re: fuente que controla la base de datos). ¿Sabes cuándo se realizará una copia de seguridad del artículo o en otro lugar donde pueda verlo? Aclamaciones. – jackocnr

+1

El artículo parece haberse movido a http://nicksergeant.com/2007/painless-drupal-revision-control-with-cvs-and-subversion-on-a-shared-host/ y la publicación adicional está en http: //nicksergeant.com/2008/my-thoughts-on-small-scale-drupal-development-to-production-environments-with-cvs-and-subversion/. –

+0

@Caroline, gracias por actualizar los enlaces – electblake

1

Puede ahorrar algo de la molestia de configurar y trabajar con SVN como se describe en el artículo de Nick si utiliza la propiedad svn:externals. Esto mantendrá su versión local de Drupal actualizada automáticamente con la rama Drupal especificada, y puede usar exactamente el mismo mecanismo para sus módulos. Además, como SVN leerá las definiciones externas de un archivo, ¡también puede ponerlas bajo control de versión!

No creo que CVS tenga una función equivalente. Sin embargo, es bastante fácil escribir un script simple que instalará automáticamente un módulo de Drupal, tomando solo una URL (he hecho esto para mantener mi propio sitio de Drupal actualizado).

En cuanto a las versiones de la base de datos, este es un problema mucho más complicado de resolver. Sugiero exportar una base de datos Drupal de "stock" a un archivo SQL y colocar eso bajo control de versión. Cada desarrollador tendría su propio servidor de base de datos privado local para usar. A continuación, podría proporcionar un script que revertiría una base de datos especificada a su versión de stock contenida en el archivo SQL.

Como un ejemplo de cómo se resuelve este problema de otras maneras, describiré la situación en el trabajo. Trabajo en una aplicación web; no usa una base de datos por lo que no sufre esos problemas. Nuestra forma de evitar la configuración repetida de los sitios es reconstruir desde el control de origen y proporcionar un programa para lograr la implementación automática de los sitios. El programa es utilizado por nuestros clientes también como su forma de crear sitios.

1

Algunos módulos como CCK y Vistas permiten exportar e importar sus datos de configuración como texto. Puede guardar estas representaciones textuales en el sistema de control de origen.

7

Tomando configuración de Drupal de la base de datos en código había sido avanzar a pasos agigantados. Dos módulos que realmente ayudan en este ámbito son:

Features - Le permite reunir entidades tales como tipos de contenido, taxonomía, vistas e incluso feeds. Estamos usando esto con mucho éxito y ha hecho posible compartir estos cambios entre los desarrolladores.

Strongarm - Permite el almacenamiento y la exportación de la variable utilizando el módulo anterior. He hecho algunas pruebas con este módulo pero no lo estamos usando, simple porque realmente no necesitamos la funcionalidad.

Estos resuelven los problemas más importantes al mantener la configuración del sitio en la base de datos. Sin embargo, no son perfectos. . . hemos encontrado módulos que no fueron compatibles o no fueron compatibles.

1

Desafortunadamente, simplemente no hay una solución buena/simple aquí. El problema es un desafortunado efecto secundario de la arquitectura no solo de Drupal, sino de todos los CMS de tipo marco donde las aplicaciones se definen tanto a través de la configuración (es decir, los datos almacenados en el db) como a través del código fuente. Ninguna de las dos opciones para administrar los datos de configuración es excelente. El primero es lo que estás haciendo: definir un solo db como canónico (es decir, el db de producción) y hacer que los desarrolladores trabajen localmente con una instantánea de la producción db y "fusionar" nueva información de configuración en el db de producción a través de la configuración manual en el sitio de producción interfaz de administrador. En el caso de subsistemas bien definidos, es decir, Vistas, es posible que pueda aprovechar las características de importación/exportación desarrolladas para facilitar solo este tipo de migración de configuración. La segunda opción, es decir, la automatización que creo que está buscando, es difícil pero puede valer la pena o es necesaria para grandes proyectos con el presupuesto para la automatización de proyectos complejos: profundizar en la estructura del sistema/módulo db y desarrollar scripts personalizados para fusionar los datos de configuración nuevos en el nivel de tabla/registro en el archivo db de producción, por ejemplo, como parte de una "creación" nocturna del último db. Temeroso de que no haya ninguna solución intermedia.

En términos de control de versiones para el seguimiento histórico de los datos de configuración, un módulo como backup_migrate le permite realizar vuelcos SQL automatizados de la base de datos. Puede elegir qué tablas son objeto de dumping definiendo un "perfil" de respaldo y puede crear uno que deje grandes contenidos, registros y tablas de almacenamiento en caché (por ejemplo, nodo, contenido_caché, supervisor) fuera del volcado, de modo que se quedó con un fragmento más manejable para el control de versiones . Algunas secuencias de comandos simples en el servidor o en otro lugar podrían tomar el último volcado y agregarlo a su repositorio.

0

Drupal ahora admite configuración de exportables que le permite mover la mayor parte de la configuración de un sitio al código. Exportables son compatibles con las variables de configuración, vistas, tipo de contenido, campos, formatos de entrada, etc. con la ayuda del módulo features.

También puede gestionar la configuración inicial no exportable y los cambios de configuración a través de un controlador central perfil o módulo. Úselo para habilitar el módulo, crear usuario, etc.

Consulte The Development -> Staging -> Production Workflow Problem in Drupal y la presentación Code driven development: using Features effectively in Drupal 6 and 7.

Cuestiones relacionadas