BLT End of Life: Cuando las decisiones técnicas se olvidan de los usuarios

El fin de vida de BLT: cuando las decisiones técnicas se olvidan de los usuarios

Resumen ejecutivo

La herramienta Build and Launch Tool (BLT) de Acquia llega a su fin de vida el 31 de diciembre de 2024. Como Technical Account Manager que ha ayudado a numerosas organizaciones con sus implementaciones de Drupal, he visto cómo esta transición pone en evidencia un desafío común en nuestra industria: decisiones técnicas que a veces pierden de vista las necesidades de los usuarios. Exploremos qué significa esto para los equipos y qué nos dice sobre el patrón más amplio de toma de decisiones técnicas.

Prepararse para la vida después de BLT

He escrito documentación para Acquia sobre cómo reemplazar las funcionalidades comunes de BLT y he compartido ejemplos de código en un repositorio público de GitHub. Seamos directos: esta transición no es tan simple como cambiar una herramienta por otra. Algunas soluciones alternativas, especialmente alrededor de los procesos de despliegue y construcción, pueden generar una fricción significativa para los equipos de desarrollo.
Si estás usando herramientas de CI/CD que dependen de blt deploy, tendrás que revisar y ajustar tus procesos con cuidado. He visto equipos que luchan con esta transición, sobre todo cuando necesitan adaptar sus estrategias de despliegue para trabajar sin los comandos simplificados de BLT.

Por qué esto importa

El impacto de perder BLT va más allá de simplemente cambiar herramientas. BLT no era solo otra herramienta de desarrollo: aportaba beneficios fundamentales que le facilitaban la vida a los equipos:

• Procesos de despliegue simplificados
• Sincronización fácil entre entornos cloud y locales
• Gestión estructurada de configuración
• Manejo organizado del archivo settings.php
• Procesos de pruebas optimizados

Aunque el proyecto Acquia Drupal recommended settings ha recogido muchas de las funcionalidades relacionadas con la configuración, hemos perdido algo crítico: flujos de trabajo de despliegue directos que funcionaban de manera confiable en diferentes entornos.

El impacto en el mundo real

Para los equipos que usan Acquia Pipelines o Code Studio, la transición fuera de BLT puede no representar problemas significativos. Sin embargo, para quienes dependen de flujos de trabajo CI/CD como GitHub Actions, GitLab pipelines o Azure Pipelines, el despliegue se vuelve más complicado.
Aquí está el desafío central: las buenas prácticas de Drupal recomiendan mantener repositorios separados para desarrollo y despliegue. Tu repositorio de desarrollo contiene los archivos de Composer, el código personalizado y las configuraciones, mientras que el repositorio git de Acquia aloja el sitio completo instalado con todas sus dependencias. BLT manejaba esta complejidad sin esfuerzo. Sin embargo, las soluciones de reemplazo actuales parecen asumir que trabajas directamente en tu repositorio de Acquia, lo cual no está alineado con estas buenas prácticas. Esta desalineación obliga a los equipos a implementar soluciones alternativas, que pueden traer sus propios problemas potenciales.
Por ejemplo, en mi publicación del blog de Acquia, detallé una solución alternativa usando el script post-install-cmd de Composer. Si bien esa solución funciona, introduce un nuevo problema: el script se ejecuta en cada operación de composer install, lo que puede ralentizar las tareas rutinarias de desarrollo. Ofrecí una posible solución limitando estas operaciones solo a entornos CI/CD, pero esto igual agrega una complejidad que no existía con el proceso de despliegue simplificado de BLT.

Ya hemos estado aquí antes

Este patrón —donde la evolución técnica genera fricción para los usuarios— no es nuevo, especialmente en el mundo del código abierto. A finales de los años noventa, participé en discusiones sobre Webmin, una herramienta de administración de sistemas basada en web. Los usuarios técnicos insistían en que editar los archivos de configuración directamente era "la manera correcta", y argumentaban en contra de las herramientas GUI por considerarlas demasiado simples o limitantes. Pero entonces vi lo que veo ahora: las herramientas que simplifican procesos complejos cumplen un propósito vital, especialmente para los equipos que necesitan enfocarse en construir y no en mantener infraestructura.
Los primeros días de Linux en computadoras de escritorio cuentan una historia similar. Mientras Windows manejaba muchos procesos técnicos de forma automática, Linux frecuentemente obligaba a los usuarios finales a realizar operaciones técnicas complejas que deberían haberse simplificado. Hizo falta que distribuciones como Ubuntu priorizaran finalmente la experiencia de usuario junto con la capacidad técnica.

¿Estamos aprendiendo?

La comunidad de Drupal está avanzando. Vemos más iniciativas que consideran la experiencia de usuario en su diseño, como la iniciativa Drupal CMS, que demuestra una conciencia creciente de hacer que las capacidades más poderosas sean más accesibles para usuarios no técnicos. Pero todavía enfrentamos desafíos, especialmente cuando el desarrollo de funcionalidades requiere un conocimiento técnico profundo.
A medida que aumenta la complejidad técnica, corremos el riesgo de perder de vista el principio básico: mantener las cosas simples para los usuarios finales. Aunque hablamos de hacer las herramientas más accesibles, nuestras decisiones técnicas a veces empujan en la dirección contraria, exigiendo más experiencia, flujos de trabajo más complejos y más recursos que no todos los equipos tienen.

¿Y ahora qué?

Si estás enfrentando la transición de BLT:

• Empieza a planificar tu enfoque ahora — no esperes hasta diciembre
• Documenta tus procesos actuales antes de hacer cambios
• Evalúa qué estrategias de despliegue funcionarán mejor para tu equipo
• Considera el impacto en tu flujo de trabajo de desarrollo, especialmente en lo que respecta a las construcciones de frontend
• Busca ayuda en la comunidad cuando la necesites — todos estamos descubriendo esto juntos

La lección real aquí

Toda decisión técnica afecta en última instancia a los usuarios, ya sean desarrolladores, editores de contenido o constructores de sitios. Si bien no debemos comprometer la excelencia técnica, hay que recordar que la solución técnicamente más elegante no siempre es la más práctica.
La transición de BLT nos da la oportunidad de reflexionar sobre cómo equilibramos el avance técnico con las necesidades de los usuarios. A medida que avanzamos, asegurémonos de no solo hacer las cosas más sofisticadas, sino también más accesibles para equipos de todos los tamaños y niveles de habilidad.
¿Has experimentado desconexiones similares entre decisiones técnicas y necesidades prácticas? ¿Cómo está manejando tu equipo la transición de BLT? Comparte tus experiencias en los comentarios.