¿Estrategia de Control de Código Fuente de Drupal?
En php estándar o proyectos basados en código fuente fácilmente mantenemos todo el código en SVN y cada desarrollador puede realizar su propia copia y colaborar en el mismo código.
Sin embargo, cuando se desarrolla un sitio Drupal, gran parte del trabajo está en "setup". Además del tema y los módulos, realmente no tiene 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 de tipo " X " en orden cronológico. El cliente comienza a usar el sitio, agregar contenido, elementos de menú, etc.
La próxima versión está planeada para agregar la capacidad de búsqueda de usuarios a esa vista. Sin embargo, la configuración para eso está contenida en la base de datos. Podemos copiar la base de datos de producción a nuestra versión de desarrollo para obtener los últimos datos mientras trabajamos en cambiar el vista. Durante ese tiempo, sin embargo, el cliente todavía puede estar actualizando el sitio, haciendo que nuestra base de datos de desarrollo no esté sincronizada. Cuando estemos listos para llevar la nueva vista a producción, ¿hay una forma más fácil de hacerlo que repetir manualmente los pasos para configurarla en la instalación de producción?
7 answers
Creo que una buena estrategia aquí es usar la API de perfil de instalación. Con install profile API puedes hacer la mayoría de las cosas que con las herramientas de administración de Drupal. La mayoría de los formularios básicos simplemente establecen variables en la tabla variables. Para poder versionar con sensatez el contenido de su base de datos sin contenido, es decir, la configuración, es aconsejable usar funciones de actualización.
En mi sitio tenemos el módulo "ec" que hace muy poco aparte de tener su ec.el archivo de instalación contiene funciones de actualización, p. ej. 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 o dos funciones de actualización de ejemplo 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 principalmente el problema de versionado con bases de datos y código Drupal. Lo usamos extensivamente. Nos permite promover nuevo código que cambia la configuración de la base de datos sin tener que reimportar la base de datos o hacer live cambio. Esto también significa que podemos probar correctamente 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;
}
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-01-05 20:43:50
Escribí un artículo sobre el control de revisión Drupal sin dolor con CVS y las mejores prácticas de Subversion hace un tiempo.
Desafortunadamente, todavía existe el problema de controlar el código fuente de la base de datos, como usted ha señalado. Hay algunos métodos sugeridos, que menciono en un post adicional.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-05-05 11:04:26
Tomar la configuración de Drupal de la base de datos en código había estado avanzando a pasos agigantados. Dos módulos que realmente ayudan en este ámbito son:
Características - Le permite reunir entidades como tipos de contenido, taxonomía, vistas, incluso fuentes. Estamos usando esto con mucho éxito y ha hecho posible compartir estos cambios entre los desarrolladores.
Strongarm - Permite el almacenamiento y 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 necesitábamos la funcionalidad.
Estos resuelven los mayores problemas con el mantenimiento de la configuración del sitio en la base de datos. Sin embargo, no son perfectos. . . hemos encontrado módulos que no eran compatibles o que eran incorrectamente compatibles.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-10 00:30:51
Podría ahorrarse algo del dolor de configurar y trabajar con SVN como se describe en el artículo de Nick si usa la propiedad svn:externals. Esto mantendrá su versión local de Drupal actualizada con la rama Drupal especificada automáticamente, y puede usar exactamente el mismo mecanismo para sus módulos. Además, debido a que SVN leerá las definiciones externas de un archivo, también puede ponerlas bajo control de versiones.
No creo que CVS tenga un equivalente función. Sin embargo, es bastante fácil escribir un script simple que instalará automáticamente un módulo Drupal, tomando solo una URL (he hecho esto para mantener mi propio sitio Drupal actualizado).
En lo que respecta al versionado de la base de datos, este es un problema mucho más complicado de resolver. Yo sugeriría exportar una base de datos" stock " de Drupal a un archivo SQL y colocarlo bajo control de versiones. Cada desarrollador tendría su propio servidor de base de datos privada 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 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 utiliza una base de datos por lo que no sufre esos problemas. Nuestra forma de evitar la configuración repetida de sitios es reconstruir desde el control de código fuente y proporcionar un programa para lograr el despliegue automático de los sitios. El programa es utilizado por nuestros clientes como su forma de crear sitios.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-13 21:12:33
Algunos módulos como CCK y Views permiten exportar e importar sus datos de configuración como texto. Puede guardar estas representaciones textuales bajo el sistema de control de código fuente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-12-16 15:42:58
Desafortunadamente, 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 framework donde las aplicaciones se definen tanto a través de la configuración (es decir, los datos almacenados en la base de datos) como a través del código fuente. Ninguna de las dos opciones para administrar los datos de configuración son excelentes. La primera es lo que está haciendo: definir una sola base de datos como canónica (es decir, la base de datos de producción) y hacer que los desarrolladores trabajen localmente con un instantánea de la base de datos de producción y "combinar" nueva información de configuración en la base de datos de producción a través de la configuración manual a través de la interfaz de administración del sitio de producción. En el caso de subsistemas bien definidos, es decir, Vistas, es posible que pueda aprovechar las funciones de importación / exportación desarrolladas para facilitar 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 podría valer la pena, o ser necesaria, para proyectos grandes con el presupuesto para proyectos complejos automatización de proyectos: profundice en la estructura de la base de datos del sistema/módulo y desarrolle scripts personalizados para combinar nuevos datos de configuración a nivel de tabla/registro en la base de datos de producción, por ejemplo, como parte de una "compilación" nocturna de la última base de datos. Me temo que no hay 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 volcados SQL automatizados de la base de datos. Puede elegir qué tablas son volcadas por definir un "perfil" de copia de seguridad y podría crear uno que dejara el contenido grande, el registro y las tablas de almacenamiento en caché (por ejemplo, node, cache_content, watchdog) fuera del volcado para que se quedara con un fragmento más manejable para el control de versiones. Algunos scripts simples en el servidor o en otro lugar podrían tomar el último volcado y agregarlo a su respository.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-07 16:18:43
Drupal ahora tiene soporte para exportables configuration que le permiten mover la mayor parte de la configuración de un sitio al código. Los exportables son compatibles con 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.
Véase El Problema del Flujo de trabajo de Desarrollo -> Estadificación -> Producción en Drupal y el desarrollo impulsado por código : uso efectivo de las características en la presentación de Drupal 6 y 7.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-04-07 18:58:58