svn - ¿Estrategia de control de fuente de Drupal?

version-control

Question

En los 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.

Sin embargo, al desarrollar un sitio Drupal, 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?

Ejemplo de escenario:

Lanzamos una versión inicial de un sitio de 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.

La próxima versión está planeada 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?

Answer 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.

Answer 2

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 la base de datos que no son de contenido, es decir, la configuració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, por ejemplo, ec_update_6001 ()

Su función principal de instalación 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 muestra o dos de nuestro archivo actual ahora sigue

// 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 principalmente el problema de las 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 apoyan 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;
} 

Answer 3

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, 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.

Answer 4

Drupal ahora admite la 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 variables de configuración, vistas, tipo de contenido, campos, formatos de entrada, etc. con la ayuda del módulo de Features .

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

Vea El desarrollo -> Puesta en escena -> Problema del flujo de trabajo de producción en Drupal y el desarrollo impulsado por código: el uso eficaz de las características en la presentación Drupal 6 y 7 .

Answer 5

Hace un tiempo escribí un artículo sobre el control de revisión de Drupal sin complicaciones con las mejores prácticas de CVS y Subversion .

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 una publicación adicional .

Answer 6

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

Features : le permite reunir entidades 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.

Answer 7

Podrías ahorrarte parte del dolor de configurar y trabajar con SVN como se describe en el artículo de Nick si usas 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 característica 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 la versión 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 este problema se resuelve 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.