¿Cómo administrar efectivamente un sitio con Drush make?

¿Qué cosas es importante tener en cuenta al administrar un sitio usando Drush make ?

drush

— Letharion
fuente

"Crear archivos", en el contexto de Drush y Drupal, define un conjunto de módulos, temas y bibliotecas que conforman un sitio. Si bien uno podría pegar todo el directorio de sitios / todos / módulos en git, el archivo make es mucho más rápido de manejar, tanto para git como para los desarrolladores. A continuación hay un archivo de creación de un proyecto mío real. He recortado mucho ya que todo el archivo tiene cientos de líneas, pero he retenido lo suficiente como para mostrar toda la funcionalidad que he usado.

; API
api = 2

; Core
core = 7.x
projects[drupal][version] = 7.14

; Contrib modules
projects[date][version] = 2.0-alpha4
projects[email][version] = 1.0

; Media and file_entity go hand in hand - please make sure they work together.
projects[media][version] = 2.0-unstable5
projects[file_entity][version] = 2.0-unstable5

; Cron modules
projects[ultimate_cron][version] = 1.6
projects[background_process][version] = 1.12

; Performance modules
projects[expire][version] = 1.0-alpha2
projects[cache_actions][version] = 2.0-alpha3

; Unstable modules
projects[menu_node_views][type] = module
projects[menu_node_views][download][type] = git
projects[menu_node_views][download][url] = http://git.drupal.org/project/menu_node_views.git
projects[menu_node_views][download][revision] = f46dd41eb8c4e693a6642a6c461afa57d99a6f1b

projects[filefield_sources_plupload][type] = module
projects[filefield_sources_plupload][download][type] = git
projects[filefield_sources_plupload][download][url] = http://git.drupal.org/project/filefield_sources_plupload.git
projects[filefield_sources_plupload][download][revision] = da374770b80fcbc0dab17158d38c8436ef29caca

projects[menu_token][type] = module
projects[menu_token][download][type] = git
projects[menu_token][download][url] = http://git.drupal.org/project/menu_token.git
projects[menu_token][download][revision] = 8c18fbb

; Libraries
libraries[mediaelement][download][type] = "file"
libraries[mediaelement][download][url] = "https://github.com/johndyer/mediaelement/zipball/2.7.0"

; Patches

; #1491150: node_load in menu_node_menu_link_insert is not safe - http://drupal.org/node/1491150
projects[menu_node][patch][] = http://drupal.org/files/menu_node-node_load-in-menu_node_menu_link_insert-1491150-1.patch

; Fix rendering of relation endpoints
projects[relation][patch][] = http://drupal.org/files/relation_table_endpoints_break.patch
projects[relation][patch][] = http://drupal.org/files/relation_bundle_permissions.patch

libraries[jquery-json-min][download][type] = "file"
libraries[jquery-json-min][download][url] = "http://jquery-json.googlecode.com/files/jquery.json-2.3.min.js"
libraries[jquery-json-min][download][sha1] = "2a4615b93c65dd50f92117c570121035a0327fee"
libraries[jquery-json-min][destination] = "libraries/jquery-json"

La línea api define qué Drush hace API para usar en el resto del archivo. Una cosa importante a tener en cuenta sobre el archivo es que todos los módulos tienen una versión específica o apuntan a una comisión específica de git. Nosotros no tenemos versiones -dev en nuestros archivos. Cuando nos presentamos en una reunión de clientes, o entregamos el archivo make al servidor Jenkins , nunca debe haber sorpresas. La versión exacta incluida en el archivo debe ser probada y se espera que pase todos los tipos de pruebas. Esto es importante para poder entregar algo de alta calidad.

En mi empresa, el acuerdo general es que cada equipo proporciona un script de shell llamado "build", en la raíz del repositorio, que es responsable de configurar el sitio, para que las pruebas automatizadas puedan ser ejecutadas por el mismo equipo cruzado. Configuración de CI.

Las actualizaciones del módulo se pueden realizar rápidamente directamente en los sitios para realizar pruebas, pero oficialmente actualizando el archivo make y reconstruyendo el sitio.

Mi equipo actualmente usa este conjunto de scripts de compilación . Sin embargo, estoy trabajando para trasladar gran parte de la funcionalidad a una extensión drush que usará mucho la provisión. Una versión CLI de Aegir si quieres.

— Letharion
fuente

Genio. Gracias por tomarse el tiempo para escribir esto es muy útil

— Clive

Sí, estoy de acuerdo con Clive, la votación como una publicación muy útil. Estoy interesado en no tener que instalar repetidamente el mismo conjunto de módulos y parches. @Letharion Le daría una calurosa bienvenida si pudiera explicar algún día cómo proceder con eso. ¿Lo instala localmente o en un servidor remoto?

— Artur

Jugando con drush make. Entiendo totalmente la razón para poner números de versión fijos allí. Sin embargo, ¿cómo los actualizas? ¿Hay un drush equivalente a drush up? En algún momento, debe actualizar sus versiones a la versión más reciente (especialmente las actualizaciones de seguridad). Tener que hacerlo manualmente con docenas de módulos parece bastante tedioso ...

— Berdir

Preguntas de Moar: ¿Tiene un archivo .gitignore o cómo evita cometer archivos "maked"? Si es así, ¿cómo se ve eso? Intenté hacer algo elegante con comodines y! pero eso no funciona para directorios.

— Berdir

Realmente no estoy de acuerdo. La falta de -dev es lo que garantiza la coherencia, no al revés. Es responsabilidad de cada desarrollador asegurarse de que se aplique el parche, lo que puede significar referirse a una revisión de git en lugar de una versión estable, pero nunca a un dispositivo impredecible que puede cambiar de una compilación a otra.

— Letharion