Sistemas como wordpress que existen en cientos , miles o millones de instalaciones, no pueden, y a veces no deben, mantenerse todos en la misma versión con un control central. Las razones van desde versione de PHP, ser de diferentes dueños las instalaciones etc. Sin embargo, el que un sistema se mantenga actualizado por si solo como los antivirus, y en ocasiones wordpress, tiene sus ventajas.
Sin embargo hay momentos donde le probelma es otro.
Ejemplo: EN el año 2010 desarrollé para un cliente , por nómina, un sistema que estaba pensado para clientes X, y y z donde los Z eran los mayores y con mas prestaciones. Deje de ver el sistema, y años espués me enteré que tenían unas 20 versiones diferentes en diferentres clientes y los sistemas no se mantenín actualizados y no podían entrar en diferentes servidores. Incluso no sabían QUE versiones tenian en cada cliente. Independientemente de que eso es un desastre como proceso, tuvimos un problema fuerte cuando solucioné algo en el código central y nunca lo pusieron en los otros. Incluso no sabian si los clientes tenian instalado que.
En tiempos modernos lo ideal sería tener instalado un repositorio CONFIABLE tipo Git. Pero que pasa cuando el código es sensible y privado ? Hace unos mesdes salió un problema en foros de sistemas por personas que pusieron sus claves de Amazon en repositorios ocultos, que visual estudio por error no hizo ocultos, y cuentas de S3 de amazon fueron hackeadas. Por lo mismo, y por los problemas de «clearing» o control de daños de posibles , ni siquiera reales contraseñas expuestas, nunca permito que se use Github como base de código sensitivo, sea por u naturaleza o porque se un cliente de pago. En todo caso prefiero instalar un fork en un server de mi empresa, y obligar a que todos los proyectos y summit sean privados.
Pero eso no resuelve el problema básico.
Vamos a ver cuatro escenarios que me estan pasando en este momento:
1 ) Hay un sistema funcional en php que maneja mas o menos 300 archivos de diversos tipos. ALrededor de la tercera parte de ellos son LEGACY además de black box. Es decir, son antiguos, no desarrollados por mí, y un desastre tal de jquery mal hecho que conviene mas no hacerles nada y dejarlos como estan en lo que se cambian por algo mejor. De momento el cliente mueve mas de cien millones de pesos y 200 toneladas de producto y no tienen problemas con mi parte del código. El Legacy se va arreglando poco a poco, pero tienen que hacer un cambio en un módulo secundario que está conctado a sistemas financieros, y que no conviene hacer en vivo por dos razones : Una que interrumpe una operación de tres millones de pesos diarios, y dos, que no hay porque hacer «reales» las pruebas. Si desconectamos el servicio oque procesa lo financiero las pruebas no pasan de eso, pero desconectar y conectar el servicio puede tener un costo potencial enorme.
2 ) Otro cliente tiene un sistema que tiene tiene actualmente solo un proveedor de un proceso crítico que se consume por Webservice. Ya desarrollé un webservice que mejora y soluciona un problema que tienen y conseguí dos proveedores alternos como plan B. Pero, como no puedo parar la operación de un sistema usado diariamente por 600 a 700 usuarios, tampoco puedo hacer pruebas porque el cliente tiene el riesgos de molestar a sus usuarios y cada usuario le da unos 2000 pesos al año.
3 ) UN cliente me pide que migre un sistema hecho por otra persona en PHP 4.4.9 con librerias de bases de datos incompatibles con la realidad actual de servers pero sus sistema ya dejó de funcionar. No es vitl pero hay un mes en promedio para arreglarlo. Lo ideal sería hacer pruebas propias COPIANDO sus datos, y que su actualización sea de archivos php previo respaldo. Así que un server debe ser autoridad en php para versiones, y otro debe ser de datos. Idealmente, al terminar las pruebas se copia un archivo en su servidor, se dice actualizar y todo su código se convierte la nueva versión con soporte para mysqli sin PEAR.
4) Hay otro sistema que tiene problemas de versiones de bases de datos, debido a que el cliente tiene dos instalaciones del software en diferentes servers, y uno se dañó. El respaldo es de hace seis meses pero no perdió información, solo que la versión actual tiene unas doce tablas mas de base de datos y unos 300 campos nuevos asi como unos 20 a 40 removidos. Se busca que el sistema autiactualice la estructura de su base de datos con un maestro, y después el código de los dos servers se actualice para que sean identicos. Preferentemente sn intervención humana.
Los cuatro problemas tienen la misma solución básica y son problemas reales a los que me estoy enfrentando en este momento. Lo que se necesita es que se actualicen contra una instalación en otro lugar, y estar seguros que no está bloqueada la dirección web base.
Además, es probable que no pueda usarse el mecanismo estáandar de «instalar y ajustar» porque solo el 2 tiene instalador. Es decir, simplemente no debería copiarse a mano a un ambiente de pruebas. Y si las bases de datos son de varios gigabytes, debe considerarse como maestro de datos al del cliente, no al revés, pro ajustar epués porque la estructura debe ajustarse, los archivos de imagen y pho deben ajustarse pero el contenido de la base de datos NO debe pasar de una instalación a otra. LO ideal sería que el ambiente de pruebas tome los archivos de producción como autoridad, y una vez que el código sea igual, invertir la autoridad. Es decir, que el de producción pueda actualizarse contra una instalación moderna que lo copió en primer lugar, en cuanto a archivos se refiere. El proceso de replicación de base de datos presenta problemas tanto por ser información confidencial, como por la no existencia de scripts uqe creen la integridad referencias con llaves foráneas. Así que, en segundo paso, debe verificarse el esquema con una herramienta diferente, que puede ser un script a la medida que vaya creando cada integridad foránea. Si consideramos que cada versión de mysql tiene sus detalles al crgar código *.sql de versiones antriores, el primer requisito es validar que la base de datos sea la misma versión. NO diferente. No se uede hacer lo mismo con la versión de php ya que rompería código u operación pero si mostrar una recomendación de actualizar la versión (y me parece que menos el problema 3 todos los otros usan por lo menos 5.3)