Los Deploys y como exportar e importar configuraciones entre entornos

 Bienvenido o bienvenida a otra semana más donde voy a hablar cosas de Endurpal. Esta semana toca lo que ya he hecho un poco de spoilers en el episodio de los pasados, que es el tema de exportar configuraciones. Es básicamente para hacer aclaraciones. Primero, como ya comenté, en Endurpal las configuraciones que se aplican a los módulos se hacen por configuración. Tienes un formulario en la edición de usuario y tú como administrador, si tienes permisos suficientes, puedes editar esas configuraciones. Y al guardar se guardan base de datos. Hasta aquí bien. El problema es que hay cosas de estas que se modifican en local o se modifican en desarrollo, en un entorno más o menos controlado para que si petan cosas no pete la web en producción. El problema viene cuando se tiene que aplicar todo esto a producción. El deploy, el pase a producción, digamos que tiene que dejarlo como una copia exacta a como estaba en desarrollo o como estaba en preproducción. Me he encontrado malas prácticas de gente que lo que hace es exportar la base de datos entera y machaca la base de datos de lo que tenemos en desarrollo o en local con lo que hay en producción. ¿Cuál es el problema con esto? Bueno, primero, depende del proyecto puede llegar a ser factible, aunque no recomendable. Pero claro, si machacas la base de datos con una copia que tienes tú en desarrollo, por ejemplo, si es una web digamos que tiene cuatro páginas, que es una página de servicios, que una empresa de quién soy, qué hacemos y formulario de contacto. Es una web que no se edita apenas, no hay contenido real, no hay en tiempo real nada. No hay problema. Digamos que la web puede estar caída un rato para hacer el pase de base de datos, pero no es grave, no se van a perder contenidos a la que se esté moviendo. Y si se pierden contenidos están más o menos controlados porque sabemos qué páginas se han creado en el último mes. Y digo en el último mes porque el problema viene con esto, con el tiempo. El tiempo desde que se cogió una copia seguridad de producción, se instaló en un entorno, por ejemplo, desarrollo, se modificaron cosas, se añadió una nueva funcionalidad o se añadió un campo o lo que se haya pedido. Ha pasado X tiempo, pongamos por ejemplo un mes y ahora tú como cliente solicitas de vale, sí, acepto, todo está muy bien, pública la producción. Vale, cojo base de datos y lo meto en producción. Como ha estado este mes, producción y desarrollo pueden ser distintos, pueden tener textos distintos. Por ejemplo, un editor de texto, un usuario puede entrar a la web de producción y cambiar el título o cambiar un texto de la home porque faltaba un acento o porque yo qué sé, o ha cambiado precios, por ejemplo. Si yo cojo la copia que tengo de hace un mes, los contenidos son los de hace un mes. Si la machaco con producción, creo que no hace falta tener muchas luces para ver de qué vas a modificar los cambios de este último mes para dejar lo que había hace un mes. ¿Verdad? O sea, es bastante lógico. Pues me he encontrado en muchos casos que hacían esto y en casos, por ejemplo, de que tenían contenido dinámico o contenido real. En el sentido de que era contenido, por ejemplo, formó ese contacto que cada día les contactaban 30 personas. Pues después de mes y medio cogían la base de datos y la machacaban. Y claro, perdían todos los contactos que estaban guardados en base de datos. Que sí, que tenían una copia en el mail. Pero después cuando querían sacar estadísticas, no podían porque tenían los mails, o sea, no tenían los contactos reales en la base de datos. No se podían hacer cálculos realistas de cuántos contactos tenían al mes. Por ponerte un ejemplo tonto. Después, si tienes un e-commerce y tienes, por ejemplo, pedidos y compras, esto no puedes hacerlo ni de coña porque pierdes las compras del último mes. O sea, pierdes el histórico de los pedidos de los usuarios. Si después entra un usuario y quiere ver su histórico de pedidos, no puede. O si, por ejemplo, se han modificado precios o se ha cambiado el stock de los productos, estás jodido. Del mismo modo, si hay webs que se permiten a los usuarios darse de alta automáticamente, o sea, registrarse por uno mismo, por ejemplo, un e-commerce, un caso común. Por ejemplo, tenemos una web donde se permite comentar a los usuarios, hay una sección de comentarios y pueden poner su contenido allí. Es el mismo caso. En el último mes se han registrado usuarios, en el último mes se han creado comentarios y vienes tú con la base de datos y me la machacas. Pues se piden los comentarios y los usuarios de este último mes. Con lo cual, machacar la base de datos es una mala praxis para temas de deploy a producción. No se debería hacer nunca. La base de datos de producción no se toca. Se coge y se duplica en desarrollo o para niveles inferiores. Pero de niveles inferiores a producción nunca. Debería estar más que claro esto. Y aún así me encuentro agencias que siguen haciéndolo. Dicho todo esto, ¿dónde entra Drupal y cuál es la mejor forma de hacerlo? Drupal tiene entidades de configuración. Significa que en local, desarrollo o en el entorno que tú quieras modificas una configuración, hay un comando que es druchfix, que desilinea comandos como programador de belleza de usar rash, que esto es para otro episodio. Y básicamente te genera los ficheros en el directorio correspondiente. Y si trabajas con git, que deberías trabajar con git, ves las diferencias de los tipos. Por ejemplo, se ha modificado que el label de un campo de ese tipo de contenido tiene este otro nombre. Porque está mal escrito o porque el label, yo que sé, antes de características ya se ha puesto características técnicas. Como el label es como título del campo. Pues al exportar la configuración, se exporta esto a código, lo metes en el git y con el git esto lo subes a cualquier entorno, a producción final. Y hay otro comando que es druchfim, que es para importar la configuración que está en código, la importa base de datos. Antes de hacerlo, te vas a decir de que se han detectado que hay estos cambios en estos archivos, que si realmente quieres aplicarlos y le dices que sí y te subescribe la configuración. No te subescribe los contenidos. Si tienes productos, comentarios, usuarios nuevos, esto no lo toca. Solo aplica los cambios de configuración. Por poner un ejemplo, si tienes contenido en un campo y ese campo se ha eliminado en la configuración, Drupal va a intentar eliminar ese campo. Con lo cual sí que puedes perder contenidos. Pero supuestamente si quieres eliminar ese campo es porque lo quieres eliminar. De misma forma, si tienes un tipo de contenido que está en producción, por ejemplo tienes un e-commerce con productos y en el producto has añadido un campo que es un campo. Por ejemplo, cuando hagas el theme, cuando importes la configuración, ese campo de color se va a crear. No va a rellenar automáticamente los contenidos del campo, pero en el formulario ya va a aparecer el campo. En la visualización del nodo se va a mostrar el campo y a finales toda la configuración que tú ya has hecho se va a aplicar en producción. Y vas a pensar, hasta aquí todo muy bien, no hay problema. Drupal es leche. Sí y no. Sí, porque comparado con otras cosas, como por ejemplo, como trabaja mucha gente en WordPress o cómo se trabajaba en Drupal 7 o Drupal 6, es una mejora impresionante. Pero hay cosas a tener en cuenta. La primera es, si la configuración en producción es distinta, porque ha de ser distinta en algunos casos, ¿qué hacemos? Si no sabes gestionar bien, la puedes liar para arriba. Vale, por poner un ejemplo tonto. La configuración del SMTP de envío de correos en producción es una y en desarrollo está desactivada, porque no quieres enviar ningún correo. Por ejemplo, o el Google Analytics, el código de Google en producción es el que toca y en desarrollo no hay ninguno porque no quieres que se cuenten las visitas. Por poner un ejemplo. O por ejemplo, tenemos un módulo en desarrollo o desactivamos las caches en desarrollo para trabajar mejor y en producción tienen que estar las caches activas y módulos de desarrollo o de editor de configuraciones quizá no queremos que estén activos. Al final esto es una configuración de qué módulos están activos y cuáles no. Con lo cual no siempre es una copia exacta la configuración que tenemos en un entorno como desarrollo o preproducción de lo que está en producción realmente. Aquí vienen a salvarnos un módulo que se llama config split. Que justamente lo que permite es tener, digamos, distintas configuraciones en distintos entornos. Se configura el módulo específicas que tenemos por poner algo, tres entornos, local, desarrollo y producción. Y específicas qué módulos o qué archivos de configuración son distintos en cada uno de los entornos. Como he dicho, por ejemplo, en local pues el... El developer no queremos tener activo, perdón, en local queremos tener el developer activo, queremos tener el editor de campos activo, queremos tener el view-duey activo y queremos tener otros módulos activos. Y por contra queremos desactivar, por ejemplo, el SMTP para que no envíe ningún correo. Después en desarrollo queremos tener el SMTP activo pero no queremos tener el... Queremos tener el developer activo y otro no. Y en producción queremos tener las de producción como tocan. Y con config split al hacer el comando de exportar o importar configuraciones, Drupal es tan listo que ya lo hace todo bien y te importa la configuración que tú tienes para cada uno de los entornos. Y eso es porque se ha puesto en un archivo en tu settings y detecta automáticamente en qué entorno estás. Con lo cual, algo que iba. Si trabajas con Drupal, con webs digamos que hace tener configuraciones distintas que realmente en la mayoría de webs recomiendo tener configuraciones distintas para no tener erradas humanas. De esto, por ejemplo, la típica de las cachés. La gente lo desactiva en local, hace cambios, exporta, no mira que ha exportado, lo importa en producción y en producción se queda sin cachés. Con lo cual si tienes una web con varias visitas el servidor sufre y la web se puede llegar a caer por tema de rendimiento. Así que yo recomiendo mucho tener configuraciones distintas por entornos y recomiendo mucho usar el config split para esta cosa de separarlo por entornos. Después, ¿dónde pueden haber también errores cuando trabajas con configuraciones cuando tienes un equipo de más de una persona? O cuando se edita en distintos entornos cuando no toca. Primero, es más rápido de explicarse ya el de se edita una cosa por ejemplo en preproducción o se edita en producción directamente porque yo que sé. El SNTP por ejemplo o el código de Google Analytics. Se ha cambiado la cuenta y se tiene que poner un código distinto. Vale, pues no te avisan de nada a ti como desarrollador y cliente final. Encuentra donde está el formulario, entra, cambia el código y le da guardar. Y hasta ahí funciona todo bien. Pasan los meses, pasan por ejemplo dos meses y te piden de hacer una cosa equis, una funcionalidad que no viene a cuento que no es tema de Google Analytics que es añadir un campo en un nodo. Y tú pues vale pues exportas, o sea lo haces en tu local, exportas y lo llevas a producción y ahí haces un theme y importas. Por claro, la configuración que está en código es la de hace dos meses con tus cambios, no esto que ha modificado cliente directamente en producción. Con lo cual vas a machacar la configuración de Google Analytics y vas a poner el código que había hace dos meses. Aquí viene el caso de o no permitas, vía permisos, que el usuario que tiene el cliente edite cosas directamente en producción de configuración me refiero o también porque me he encontrado que no es culpa del cliente, sino que es culpa de alguien de la misma agencia que para ir rápido hace el arreglo en producción. Sin avisar a nadie y ni aplicar estos cambios después en código, con lo cual, bueno, si apaga el fuego esta semana, por aquí un mes, dos meses o cuando suben los cambios correspondientes, el fuego digamos que renace de sus cenizas y se salpican la cara. Vale, son cosas ten en cuenta. Y después, cuando trabajas con varias gente al mismo tiempo en cada uno con su entorno local, por ejemplo, puede ser de que se machacan configuraciones porque tú estás modificando configuraciones de distintos tipos de contenido y la otra persona también está modificando configuraciones de los mismos tipos de contenido. Con lo cual salen conflictos en el kit porque se ha modificado el mismo fichero de configuración. Aquí te recomendaría de que cuando trabajas con equipo separe bien las tareas que hace cada persona e intenta dentro de lo posible que sean tareas, digamos distintas, que no esté todo el mundo tocando lo mismo al mismo tiempo. O sea, no tengas dos o tres personas tocando el mismo tipo de contenido o los mismos permisos de usuario o X cosas, porque al final te salen merch y no es el que es un problema, porque al final se puede solucionar, pero sí que es un poco pérdida de tiempo. Y digamos que la fácil solución es intentar compartimentar mejor las tareas que hace cada persona y que no se machaquen entre ellos los cambios que ha hecho uno o el otro. Si trabajas en equipo y no estás tú solo, has de coger la costumbre de que cada vez que te bajas código, has de importar la configuración a tu base de datos, porque si no cuando exportes tu base de datos al código, vas a machacar el código que tenía otra persona. Y en esa parte del trabajo, la mayoría de las tareas que te vas a descargar son de cómo trabajar con un equipo de desarrolladores, que no sé hasta qué punto tú que me escuchas vas a hacer esto o vas a empezar por la vía rápida de soy fila, todo yo solo, y no te vas a preocupar de estos temas. Y nada más, creo que ha quedado más o menos claro el tema de configuraciones, que es muy útil saber cómo funciona, que te ahorra trabajo y te ahorra muchos errores cuando sabes usarlo muy bien. Y realmente, por ejemplo, si tú eres un cliente que tienes una web, yo solicitaría expresamente que te confirmen de que salen a trabajar exportando e importando configuraciones porque te sorprendería. La de veces que me he encontrado con agencias que no saben cómo va esto, o que ni siquiera tienen Git, que eso también es otro tema. Y si eres alguien, un desarrollador junior, quiero que demostres que sabes cómo funciona todo esto, te abre más puertas que otro junior que no sabe nada de Drupal ni sabe nada de cómo exportar o importar configuraciones. Así que también echa un ojo a la documentación y básicamente en tu local haz un par de pruebas y a ver rápidamente cómo funciona. No hay mucha complejidad tampoco. Y nada más, si te ha gustado el episodio de hoy, dale 5 estrellitas en todas partes, en Spotify y en Apple, sobre todo. Y nada más, hasta la semana que viene. Chao.