Eficientizar el proceso de Actualización de Versiones

Buenas tardes:

Nuestra Universidad tiene G3 en forma centralizada a la que acceden 4 Facultades, una escuela pre universitaria y 3 o más carreras que dependen directamente de Rectorado, cada vez nos resulta más difícil establecer fecha para actualizar versiones debido a que cada responsable maneja tiempos académicos diferentes y eso complica el ponernos de acuerdo en la parada del sistema.

Estaba pensando otra forma de realizar el upgrade y leyendo el foro encuentro que en capacitaciones explicaron una modalidad que es similar a lo que estaba pensando.

Es posible lo siguiente?

Partimos de una copia del servidor de producción, lo llevamos por ejemplo de versión 3.18 a versión 3.20.1, hacemos todas las pruebas necesarias, compartimos con los usuarios para que también prueben la nueva versión, etc.

Mientras tanto el servidor de producción continuó funcionando en versión 3.18, por lo cual la otra versión ya quedó desactualizada en datos. Para actualizarla, hacemos un dump de la BD productiva 3.18, la restauramos en el servidor 3.20.1 y corremos los scripts de conversión (migrar la base de negocio).

De esa forma, la parada del sistema no llevaría más que un par de horas creería, pero no tengo en claro si el proyecto quedaría correctamente estructurado, tendría algún inconveniente o estaría faltando algún paso.

Aguardo opiniones y otras posibles soluciones para mejorar los upgrade de versión en nuestro caso.

Muchas Gracias

Ezequiel Molina
Fac. de Cs. Agrarias - UNJu

Hola Ezequiel, te cuento como lo hago yo quizá te sirva.

si se crea un nuevo servidor desde cero con la nueva versión para poder migrar la base se debe

  1. Hacer una instalación de la nueva versión desde cero creando una base sin datos.
  2. cargar backup de base de datos de producción actual ambiente postgres de la nueva versión
  3. pasar la carpeta de perfiles en instalacion/i__desarrollo/p__guarani/ (darle permiso a la carpeta primero) *****2
  4. verificar que en el archivo instalacion/instalacion.ini tengas: chequea_sincro_svn = 0
  5. ir a instalacion/i__desarrollo/global/datos.sql eliminá las entradas que comiencen con "INSERT INTO apex_checksum_proyectos…
  6. Ir a bin y ejecutar ./toba instancia regenerar -i desarrollo
    (esto hace que toba tome todas las nueva funcionalidades de la nueva version esquema desarrollo)
    (en la pregunta elegir la opción n)
  7. Luego compilar los metadatos de Toba Usuarios: ./toba proyecto compilar -i desarrollo -p toba_usuarios
  8. en bin ejecutar ./guarani migrar_base (con esto pasamos el esquema negocio a la nueva versión)
  9. Revisar las personalizaciones existentes sigan funcionando en la nueva version
    (ver si los permisos hay que darlos despues de paso 6)

*****2
si se quiere recuperar los perfiles primero hacer esto

a)Exportar los perfiles de la instalcion vieja
guarani instancia_exp_local
b)Pasar lo generado en la carpeta de la nueva instalación
<ruta_gestion>/instalacion/i__desarrollo/p__guarani/perfiles
c)Tener configurado usar_perfiles_propios =1 en el archivo
<path proyecto Guaraní>/instalacion/i__desarrollo/instancia.ini
d)En <ruta_gestion>/bin regenerar la instancia ./guarani regenerar
e)si es producción tener descomentada en www/aplicacion.php la linea define(‘apex_pa_metadatos_compilados’, 1);
y compilar <ruta_gestion>/bin/./guarani compilar

Espero te sirva, saludos

Hola Ezquiel!

¿Que parte de la documentación es la que les consume mucho tiempo?

Saludos!

Hola Luciana: Gracias por tan detallada información! Vamos a estar revisándola con detenimiento y seguramente probando.

Hola Sergio:

Por lo general en las versiones hay que actulizar la plataforma, en versión 3.20.1 por ejemplo hay que tener PHP 7.4 y eso nos dió muchos problemas, tanto así que (en ambiente de desarrollo) tuvimos que cambiar el sistema a Debian 10.

Todo lo relacionado a Subversión también siempre nos lleva un buen tiempo de análisis, y dejar funcionando las personalizaciones correctamente, etc.

La parte de comandos propios de toba y guaraní es la que más rápido se ejecuta. Justamente todo lo anterior pensamos en tenerlo preparado y probado en otro servidor y allí llevar la BD de producción y seguir con los pasos necesarios para llevarla a la última versión.

Ezequiel

Para pasar a la 3.20 de la 3.18 también cambia la versión del yarn (revisá eso también)

Revisé en la documentación y el único cambio sería PHP 7.4 o vi mal?

Yarn en ambas figura 1.19.1 o superior

jaja entonces yo lo tenía desactualizado antes

Con respecto a estos temas, tenemos una documentación que está en desarrollo, en la cual se actualiza el ambiente de producción, en una nueva instalación desde 0.

Por favor, escriban cualquier mejora que crean conveniente

Saludos!

Muy bueno Sergio! estaremos atentos a la nueva documentación.

Saludos.

Ezequiel

Hola

Buenísimo, pueden probarla desde el link que les pasé en el mensaje anterior, quedamos atentos a cualquier consulta!

Saludos!