Conciliar versiones de desarrollo y produccion


([N1] Spicer) #1

Estimados,

Ultimamente he tenido mucho jaleo por el hecho que los clientes tienen una versión de producción y yo trabajo sobre otra distinta, de desarrollo. Al momento de implementar, resulta que los clientes tienen datos reales, actualizados, y yo tengo datos ficticios y desactualizados. Pero la versión de la aplicación obviamente es más avanzada en mi entorno de desarrollo que en la que tienen los clientes.

¿Cómo hacen para que el proceso de remplazo resulte fácil y no haya pérdida de datos?. Para colmo de males, la solución se compone de dos aplicaciones (CONFIG y CONTAB), cada una con su proyecto de datos. CONTAB hereda a CONFIG.

Se agradecen las sugerencias


([N1] wikan) #2

Buenas, yo en mi caso uso.
El traspaso de campos cuando sea necesario
Guardo en una variable el número de versión y ejecuto procesos de actualización cuando hay que modificar datos.

De todas formas, si quieres estar mas seguro, descarga una copia de los datos del cliente y es una prueba de actualización.


([N1] Spicer) #3

De acuerdo, pero operativamente…? Es decir, uso el InstallBuilder para obtener una copia de los datos de producción y luego la uso en una instancia nueva en mi entorno de desarrollo?


([N1] wikan) #4

No se como tienes desplegados los clientes, para usar InstallBuilder deben tener licencia de desarrollo.

Yo obtengo una copia de los datos (tablas) y los los pongo en mis carpetas de desarrollo, así de vez en cuando actulizo los datos de ese cliente para trabajar con “datos reales”


([N1] Spicer) #5

¿Y cómo haces eso? (obtener los datos), ¿simplemente copias el contenido de las carpetas desde el disco del servidor?


([N3] pacosatu) #6

Hola,

O lo he entendido mal o lo que estáis planteando sería una locura. ¿No vale simplemente con reinstalar el vin? La APP y DAT se sobreescriben con la nueva versión y las instancias de datos serán actualizadas con las nuevas estructuras de tablas. Por lo menos esto es lo que me vendieron.

El traspaso de datos se automatiza con los campos de traspaso.

Por favor, aclararme esto.

Saludos
Paco Satué


([N1] Spicer) #7

Hola,

Efectivamente, eso es lo ideal. Sin embargo, de alguna manera tengo que hacerme cargo de traerme los datos de producción del cliente, pues si sobreescribo con la nueva instancia, se pierden.

Actualmente hago migraciones de tablas via Excel, y es un infierno


([N3] blanyi) #8

Hola Spicer (no se si este es tu nombre, porque no firmaste el mensaje).

Yo no he tenido problemas al momento de actualizar la aplicación que tengo en Velneo para un cliente. En su momento tuve la misma inquietud que tu y lo que me recomendaron fue generar un nuevo .vin en blanco (sin agregarle ninguna datos, o mejor dicho tabla).

Con el nuevo .vin voy a donde el cliente y desde el vadmin elimino las instancias de datos y de proyecto de la aplicación y luego elimino la aplicación (hecho de esta forma lo elimina, los datos del cliente). Después de esto instalo la aplicación que ya viene con la actualización en el nuevo .vin y listo. Los datos que tiene el cliente son respetado, no se alteran para nada. Si has agregado nuevos campos o tablas, lógicamente estos aparecen vacíos.

Claro que para hacer esto debes tener en cuenta lo siguiente:

  • Si agregas nuevos campos a una tabla existentes debes colocarlos al final, si los ubicas en otra posición podría alterarte el contenido de la tabla (de todos modos esto sería bueno que lo confirmes con alguien más, para ver si aun esto es así, o haz la prueba tu,yo aun no lo he probado.)
  • Si agregas nuevas tablas y necesitas cargarlas a productivo con datos que ya tu le has montado en desarrollo, entonces solo esas tablas se pueden agregar al .vin nuevo que estas generando. Esto debes hacerlo solo la primera vez que esa tabla entra en la actualización de tu cliente. Si lo vuelves a hacer provocaras que se sobrescriban los datos que tiene tu cliente con los que tu estas metiendo en la actualización.
  • De todos modos te recomiendo que hagas una copia de la carpeta de datos de tu cliente y también conserves una copia de cada .vin con el que actualizas, por si después de la actualización ocurre algún desastres puedas desintalar la actualización que acabas de hacer y volver a instalar la vieja versión y por último volver a colocar los datos de los que hiciste el backup.

Espero haber entendido tu pregunta y que mi respuesta te ayude.

Que Dios te bendiga.

YIMY MORA ACONCHA



([N3] pacosatu) #9

Hola Spicer.

No es lo ideal, es como tiene que ser.
Andar con migraciones desde luego es un infierno, y ¿con cada cambio de versión?
Prepárate para el caso peor: que no puedas traerte los datos del cliente porque son privados o protegidos. Así que lo debes hacer como está previsto. Velneo nunca machaca las tablas si éstas existen previamente.

Si no fuera así, ¿para qué narices quiero vServer?

Saludos
Paco Satué


([N1] Spicer) #10

Estimado Yimi,

¡Qué gran idea, un VIN en blanco! No se me había ocurrido… efectivamente, al hacer eso, y mantener intacta la carpeta, debiera respetar todos los datos.

Lo probaré en cuanto pueda

Muy agradecido, de verdad!


([N4] eic) #11

Hola.

Aunque un archivo VIN contenga ficheros de tablas, si el instalador detecta que esas tablas ya existen, nunca las sobreescribe. Por tanto, los datos de tu cliente están siempre a salvo, incluso aunque tengas un VIN en el que le hayas incluido archivos de tablas.

De todos modos, yo suelo hacer un VIN en blanco para las actualizaciones posteriores (después de la primera instalación), simplemente porque ocupa menos.

Esta es, precisamente, una de las grandes ventajas de Velneo. Creas el VIN, lo instalas en el cliente, y ya está.

Eso sí, en tu caso, seguramente haría dos VIN: uno para cada solución que tenga una carpeta de datos distinta.


([N2] ramiro) #12

Buenos dias:

Respecto al comentario de que “Si agregas nuevos campos a una tabla existentes debes colocarlos al final, si los ubicas en otra posición podría alterarte el contenido de la tabla…” estaríamos apañados si fuera de esta forma. Coloca los nuevos campos donde te convenga y usa el Traspaso de Campos si cambias el nombre de alguno existente. Funciona perfecto…

Tras la primera instalación, como bien ha dicho Fran Varona, lo más limpio es instalar el Vin vacío. Si has añadido Tablas y quieres ponerlas en destino con datos, lo que me parece mejor es enviarlas previamente vía FTP o SDV y después instalar el VIN que las reconozca como tales Tablas de la nueva versión.

Tengo una instalación en continuo crecimiento pero ya en producción (en Cloud) desde hace meses y con un ritmo de cambio de unas 3 actualizaciones diarias. He hecho cientos de modificaciones en Tablas y Campos que ya tenían datos y no he perdido información en ningún momento.

Para las pruebas locales descargo periódicamente una copia de seguridad de los datos del Cloud que sustituyen a los datos de mi servidor. Cuando la instalación está en local (en el servidor de algún cliente) lo que copio son las carpetas de datos que me interesen y las pongo en mi servidor.

Saludos. Ramiro


([N1] Spicer) #13

Genial!
Muchas gracias a todos por la ayuda


([N3] pacosatu) #14

Hola.

Para no confundir a los nuevos programadores podríamos hacer un resumen de los conceptos básicos a tener en cuenta para actualizar una Aplicación en Producción.

  • vServer de forma nativa tiene los mecanismos necesarios para actualizar una Aplicación en Producción de forma segura y fiable. ¡Faltaría más!

  • Con vDevelop estamos editando los proyectos de Aplicación (código fuente) y los proyectos de datos (estructura de las tablas). En ningún caso con vDevelop generamos contenido en las tablas (si no contamos las tablas estáticas).

  • Una vez terminado el trabajo con vDevelop y probada la aplicación en desarrollo, se genera un fichero .VIN con vInstallBuilder. El fichero VIN se compone únicamente de los proyectos de Aplicación y Datos, es decir, código fuente y estructura de las tablas.

Existe la opción, si es necesario, de añadir al VIN algunas tablas para que la Aplicación disponga de ellas. Por ejemplo: queremos incorporar a nuestra aplicación las tablas de Códigos Postales y Poblaciones.

Normalmente el VIN va sin tablas (lo que se conoce como VIN vacío), pero siempre va con el código fuente y la estructura de las tablas (o sea la Solución).

  • El fichero .VIN es el que llevamos a Producción (Cliente). El fichero VIN actualizará los proyectos de Aplicación y Datos del vServer.
    Ahora viene lo más importante: cuando se reinicia la Solución, las instancias de Aplicación ejecutarán el nuevo código fuente y las instancias de Datos actualizarán la estructura de las tablas a partir de la nueva estrutura del proyecto de Datos.

Las tablas que ya existen verán actualizada su estructura y las que no existen se crearán vacías, pero NUNCA SE SOBRESCRIBEN DATOS.

Así que no tiene sentido incorporar tablas al VIN, excepto cuando queremos instalar una Aplicación con datos de prueba o incorporar tablas auxiliares.

  • En vDevelop, cada vez que pulsamos F5, se producen las mismas acciones que realiza el VIN en Producción, se reinicia la Solución en desarrollo con los cambios realizados (código fuente y estructura de tablas).

  • Por otro lado, cada Instancia de datos apunta a una carpeta donde se guardan las Tablas de la Aplicación. Estas tablas son ficheros comunes y pueden manipularse como tales.
    Por ejemplo: cuando queramos sustituir la tabla de Códigos postales por una nueva, simplemente paramos la Instancia de Datos y sustituimos los ficheros de dicha tabla. Por supuesto los podemos hacer remotamente por FTP, SDV, …

  • El nuevo subobjeto “Traspaso de campo” facilita la migración de información entre campos de una Tabla y control de versiones. Entonces ya podemos cambiar el identificativo de los campos.

Lo que se llama Migración de datos no tiene nada que ver con los .VIN. Éstos actualizan la estrutura de tablas y las Migraciones habrá que programarlas con código fuente en la Aplicación.

  • Por supuesto, lo que es sagrado son los nombres de las Tablas, nunca deben cambiarse o habrá problemas en la actualización.

Espero que estas anotaciones aclaren este tema y se pierda el miedo a actualizar aplicaciones en producción, (haz copia de seguridad siempre, por si las moscas).

Todo este rollo no quita el hecho de que el vAdmin está muy verde y torear con aplicaciones complejas con mucha Herencia sea una experiencia extresante.

Saludos
Paco Satué


([N2] ramiro) #15

Un matiz sobre el (magnifico) artículo anterior en la parte relacionada con los nombres de las Tablas…

Precisamente este fin de semana me apetecía cambiar el nombre de una Tabla que ya tenía datos.

Hice los cambios pertinentes en el proyecto pero no lo instalé
Cerré la instancia de datos en Cloud
A través de SDV renombre manualmente las Tablas e indices
Instalé la nueva versión, reinicié instancias y a funcionar

Por tanto ese cambio también es viable…

Saludos. Ramiro


([N3] pacosatu) #16

Hola Ramiro.

Efectívamente, estas cosas se pueden hacer si se entienden las tripas de vServer.
El fichero VIN no contempla el renombrado de tablas pero todo llegará.

Saludos
Paco Satué