A preocupación máis lóxica diante da renovación é esta: “vas tocar o meu sitio”.
Si, todos os sitios terán que pasar polo novo sistema. Pero iso non significa que os cambios se improvisen directamente no servidor que está en funcionamento.
Antes de tocar a rede real, traballamos cunha copia completa.
Clonar a rede enteira
A inicios de verán montei unha copia local de Fala.gal.
“Local” significa que funciona nun equipo de traballo, separada do servidor público. Os sitios, as entradas e as imaxes están aí, pero esa copia non é accesible para as persoas usuarias nin para os visitantes.
Non é unha instalación baleira de WordPress. Inclúe a base de datos e todos os ficheiros da rede.
A base de datos ten 18.452 táboas. Os ficheiros ocupan 16 GB e son máis de 106.000. Neles están as imaxes e outros materiais acumulados durante seis anos.
Para adaptar esa copia ao novo enderezo de traballo fixéronse 146.499 substitucións de enderezos.
Esta escala é precisamente a razón pola que hai que ensaiar.
O ensaio da actualización
A copia serviu para probar a actualización de WordPress desde a versión 6.5.8 ata a 7.0.2.
Actualizáronse todos os sitios en menos de tres minutos.
O tempo non é o único dato importante. Despois revisei o rexistro de erros, é dicir, o ficheiro no que o sistema anota problemas técnicos que poden non verse a simple vista.
O rexistro quedou limpo.
Isto non demostra que todas as páxinas se vexan perfectamente nin que non exista ningún fallo puntual. Demostra que a actualización xeral pode completarse e que non produce erros técnicos evidentes na base da rede.
Que detecta unha copia así
Un ensaio completo permite comprobar se WordPress actualiza, se a base de datos responde e se os temas e plugins provocan erros.
Tamén permite probar scripts de migración e repetir unha operación tantas veces como sexa necesario.
Se algo rompe, rómpese na copia.
Pódese restaurar, corrixir o proceso e volver empezar sen afectar a rede pública.
O que non detecta automaticamente
Unha proba técnica non pode decidir se unha páxina segue sendo bonita, se unha cabeceira conserva a intención orixinal ou se unha combinación concreta de bloques quedou ben.
Ese tipo de problemas require revisión visual e probas con persoas usuarias.
Tampouco todos os sitios utilizan as mesmas funcións. Un erro pode aparecer só nunha páxina antiga ou nunha combinación pouco habitual.
Por iso a copia completa non substitúe o piloto. É a primeira capa de seguridade, non a última.
Dar prazos sen inventalos
Probar o proceso permite saber canto tarda, que pasos necesita e onde poden aparecer problemas.
Sen este ensaio, calquera prazo sería unha estimación baseada nunha rede ideal que non existe.
Agora sabemos canto ocupa a copia, canto tarda unha actualización xeral e que operacións previas son necesarias.
Aínda quedan por medir as migracións visuais e a revisión de sitios personalizados. Eses datos sairán do piloto.
O seguinte paso é seleccionar sitios, aplicarlles o novo tema dentro da copia e comprobar que partes se poden automatizar e cales necesitan intervención manual.
