Patologías, DevOps y Drupal (7)

En los inicios de mis desarrollos con Drupal CMS , nuestro flujo de trabajo (Workflow) era bien rudimentario. Se basaba en, de forma iterativa, ir ensayando las diferentes funcionalidades requeridas, generando así múltiples maquetas que se iban acumulando en mi disco duro. Con sus correspondientes bases de datos. Algo chapuza, vaya, francamente.

El hecho de que Drupal tiene el defecto patológico de no hacer una distinción práctica de código, configuración y datos (estos últimos comparten la base de datos) complica más las cosas.

Ese defecto ‘de fábrica’ ha sido corregido ya en la nueva D8 (en la que se ha reescrito el 70% del código). Mezclar contenidos y configuración en la base de datos (BBDD) hace que tengamos que hacer malabarismo entre los diferentes entornos de trabajo online. Pongamos, por simplificar,

  • Desarrollo . ‘Dev’
  • Y Producción.‘Prod’

DevOps para tod@s o «La fontanería subyacente » …

En su día, compartía con nosotros @victorkane , que el quid de la cuestión en el desarrollo de Drupal CMS son en gran medida todos los procesos de DevOps que subyacen, y su (no poca) complejidad. Aunque, naturalmente, Drupal tiende a esforzarse en abstraer al desarrollador de esa ‘fontanería’ básica.

NOTA : por cierto, frameworks más recientes… que estamos probando, parecen emerger con “facilidad de uso para el desarrollador, ya en sus genes… (p.ej.: Laravel | PHP ) Así… como la natural evolución, decíamos, de Drupal 8.

Ocurre que si hemos trabajado en el agregado de nuevas funcionalidades al código fuente base en el entorno, pongamos de desarollo / Dev ( por simplificar) en nuestro PC. Esta nueva configuración + código, debe ser ‘subida’ o desplegada ‘upstream’ al entorno-servidor de producción.

Y para ello… nuestro mejor amigo es el Drupal+Bash , ‘drush’. Que nos facilita la tarea de sincronizar,

  • por un lado, (nuevo) código ‘upstream’
  • por el otro, BBDD y ficheros de contenido de usuario… ‘downstream’

Una vez más, una imagen vale más que mil palabras .

Platform as a Service ( PaaS) al auxilio

En el ámbito más orientado a herramientas como Drupal, hemos comprobado que se ha hecho muy popular Pantheon.io … que no hemos tenido (aún) el gusto de conocer en persona y experimentar con él.

Naturalmente tenemos en la industria un amplio elenco de herramientas – plataformas (PaaS) que nos facilitan la labor. La de nuestra preferencia, hoy en día es Platform.sh .

No resulta muy útil, ante nuestra necesidad expresada anteriormente… orquestando todo lo expuesto anteriormente… de forma natural con el ‘Git workflow’ (para control de versiones) como base.

 

Mención especial a la calidad de la documentación ofrecida, pues te va guiando hacia ese camino…, de forma bien documentada :

https://docs.platform.sh/frameworks/drupal7.html

Así como el canal de atención al usuario, muy proactivo.

La potencia de Platform.sh parece emerger de la capacidad para replicar entornos online con tecnología LinuxContainers (LXC) en cuestión de segundos…

Todo ello bajo tarifas asequibles para desarrolladores, por unos pocos €uros al mes… como hemos podido comprobar.

Sin olvidar que más allá de la (auto)magia ( PaaS) de Platform, trataba de explicarme, lo que subyace son tres comandos Drush ( Drupal – Bash ), al estilo y la posibilidad de drush alias … y aunque conociendonte, quizas prefieras Bash scripting con umas gotitas de Drush y bla bla… .

La clave en todo esto, es… “no dejar de ver el bosque … no sólo el árbol ” ?… y KISS ( Keep It Simple Stupid) en medida de lo posible !

‘Have Fun! / Que os divirtáis’

28/01/2018

Posted In: softwareLibre

Etiquetas: , , , ,

Leave a Comment