Crear solución de prueba sin dejar la escoba


([N1] Spicer) #1

Estimados,

Tengo una aplicación que se basa en dos soluciones, una hereda a la otra. El cliente dispone de un servidor en el cual tengo funcionando la última versión productiva. Hago los desarrollos en mi notebook, y una vez validados, los subo al servidor. El nombre de la solución de desarrollo y de producción es la misma; al momento de subirla, hago un VIN y remplazo mediante vAdmin

Lo que quiero hacer ahora es generar en el servidor del cliente una instancia de testing, completamente independiente de la de producción, para que puedan ‘jugar’ con las nuevas funcionalidades sin afectar en absoluto los datos de producción.

Para evitar cualquier tipo de equivocación, lo que quiero es copiar la solución de desarrollo a otra solución con otro nombre, cambiarle algunas cosas y subirla como si fuera una solución distinta, aunque el contenido sea básicamente el mismo. Para yo estar tranquilo, es realmente fundamental que la solución tenga un nombre diferente, pues una equivocación puede ser fatal.

¿Me podrían indicar cuál es la forma más fácil o eficinte de hacer esto?

Muy agradecido!


([N3] krear) #2

Hola @spicer!

Me parece una muy buena consulta y yo también hace tiempo que no logro encontrar la mejor manera para hacerlo, no entiendo porque no existe un simple “Guardar como” de la aplicación en la que estamos trabajando, como tiene la mayoría de los programas. Alguna vez tuve la necesidad de crear una solución a partir de otra reutilizando el máximo posible y en soporte indicaron usar herencia o sino “Pegar Como” de todos los componentes.

Incluso a mi me ha pasado también que el cliente tiene instalada la versión en producción, yo sigo haciendo mejoras o nuevas funcionalidades en mi equipo de desarrollo, y ante de estar terminadas y testeadas resulta que tu cliente te solicita una simple variación en un informe, un nuevo informe muy simple o cualquier otro cambio urgente.

En ese momento que hago??
-Si el cliente tiene un servidor con licencia de edición me arriesgo a tocar para luego copiar los cambios a mi versión de desarrollo e intentar no olvidar nada!
-Si el cliente en su servidor no tiene licencia de edición, aquí se me viene la noche! porque la versión actual de desarrollo aun no está terminada!. Pues en este caso he tenido que hacer malabares. Tener una maquina virtual con vserver, vdevelop, vadmin y vinstall para poder instalar la versión que tiene el cliente, realizar los simples cambios y luego subirla al servidor. Luego copiar estos cambios a la versión de desarrollo que está en otro ordenador.
-Otra solución podría ser tener otro vserver N1 para que el cliente vaya probando. Eso sí, tendrás que hacer una copia de las soluciones, datos y configurar nuevamente los accesos de tu cliente. Otro inconveniente que puedes encontrarte es que la versión del nuevo N1 sea más actual de la que tiene tu cliente y la que tienes tú para desarrollar.

En fin… siento no poder ayudarte en esto, y estaría muy bien que Velneo nos oriente en como debemos tener preparado nuestros equipos de desarrollo para estos casos que suelen ser muy habituales.

Espero que alguien pueda ayudarnos!

Pablo


([N1] wikan) #3

++++++1
Esto se echa de menos desde el principio, aunque Velneo siempre te responderá, la herencia…Poder copiar y pegar una solución, guardar como, duplicar, etc. Llamarlo como quieran, era un punto fundamental de las versiones anteriores 6,5,etc

Poder duplicar una solución, o simplemente un proyecto…


([N1] aztecmexico) #4

Es y no es fácil, las posibilidades son bastante amplias, cada una con sus ventajas y sus desventajas, ¿qué hago yo?.

Situación: Quiero tener una aplicación de preproducción en el mismo servidor que usa mi cliente para que puedan probar libremente nuevas funcionalidades.

Opciones.

  1. Genero una máquina virtual en la que activo un vServer express, el cual en muchos casos sirve, a menos que los datos de prueba sean demasiados o los catálogos muy grandes, etc. aquí no tengo que cambiar nada.

  2. Genero una “copia” de mi solución actual con “OTROS nombres” para cada proyecto, tanto de datos como de aplicación. Esta “nueva” solución la instalo en el mismo vServer de producción de mi cliente y genero las instancias correspondientes obviamente utilizando una nueva carpeta de datos compartida.

Procedimiento:
Consideraciones iniciales.
Habrá que “mapear” la totalidad de cajas de aplicación y datos, tanto propias como heredadas (vBase, vErp, vDiseño, etc) en vDevelop menú soluciones, opción vista de todas las abiertas, ojo, solo debemos tener abierta la solución principal de nuestro aplicación, para ver únicamente dicha solución más las heredadas.
Aquí viene un punto importante, si no vamos a tocar el código de las heredadas “estándar”, digamos vBase, vDiseño, vMapJS, u algunas otras propias, podremos utilizarlas tal cual en nuestro proyecto de preproducción, considerar también si deseamos compartir las carpetas de datos de dichas soluciones o si deseamos crear nuevas sin compartir ningún dato de las de producción.
Para este ejemplo digamos que podríamos en un momento dado “tocar” o modificar código de las heredadas.

El procedimiento entonces será:

  • Crear una nueva solución “completa” con un nuevo nombre.
  • Crear la “estructura” de cajas de aplicación y datos, todas y cada una de ellas con un nuevo nombre, esto es “imprescindible”, ya que al instalar dicha solución en el mismo servidor de producción, si dejamos algún nombre de caja igual que el original, dicha caja sobreescribirá la de producción.
  • Copiar primero todas las cajas de datos comenzando de la más baja hacia arriba, una por una cuidando que si alguna caja es punto de unión de dos ramas, antes de copiar dicha caja habremos de haber copiado primero sus ramas, una vez hecho esto ya copiamos la caja “pivote”.
  • Copiar ahora todas las cajas de aplicación, igual de abajo hacia arriba.

Siguiendo este procedimiento y cuidando el orden en que copiamos no tendremos mayores problemas, y podremos instalar dicha solución en el mismo servidor, con otro nombre y en otra carpeta de datos, ya solo será dar los permisos a los mismos usuarios ya dados de alta a dicha solución.

Cuando haya que actualizar la solución de producción, simplemente abrimos ambas soluciones, borramos el contenido completo de cada caja y lo sustituimos con una copia “normal” ctrl-c ctrl-v cuidando siempre copiar primero cajas de datos y luego cajas de aplicación que hayan sido modificasas en preproducción.

A mi me funciona y nunca he tenido problemas con este método, y aún proyectos algo grandes no me toma más de 5 minutos hacer dichas actualizaciones, reitero, cuidando el orden al momento de hacer las copias.

La única pega que hasta el momento me he encontrado es que si tienes archivos adjuntos en el proyecto, debes borrarlos todos y volverlos a crear con cada copia, ya que si editas el proyecto en producción y desde vDevelop intentas utilizar el inspector de errores, el mismo romperá hasta que no arregles lo de los adjuntos, si bien es un problema no creo que sea grave una vez conocido. Ojo, solo rompe el vDevelop al usar el inspector de errores.

Si necesitas mayor apoyo con gusto te paso mi skype, aztecmexico, donde te podré ampliar mi experiencia y cuidados o detalles extras a tomar en cuenta.

Saludos.

Martin Ibarra.


([N1] VictorMC) #5

Saludos a todos.

Creo que no hay que rizar el rizo… bueno eso creo yo :slight_smile:

Al parecer no es muy conocida aún la funcionalidad especial con la que cuenta el vServer monopuesto.
Me refiero a que el vServer en monopuesto (solo este tipo de licencia vServer) lo puedes ejecutar en el puerto que quieras dinámicamente, por lo que puedes ejecutar tantos vServer monopuesto como quieras en un mismo equipo, desde luego requiere un usuario distinto por vServer.
Esta característica la utiliza el mismo cloud de Velneo y otros tantos que ofrecen externamente servicios de vServers en la nube.

Por lo que Spicer y amigos, supongo que esto solucionaría su caso.

Muchos éxitos vEmprendedores.


([N3] blavan) #6

Y cual es el problema de dar de alta al cliente en la nube como N1?


([N1] aztecmexico) #7

Hola Victor, buen día, un gusto saludarte.

Lo de rizar el rizo, pues depende de las necesidades, un verdadero entorno de preproducción implica que no solo un usuario ataque o consuma la aplicación, sino que varios a la vez hagan sus pruebas correspondientes, y de igual manera evaluar el rendimiento de la misma en un entorno lo más parecido posible a la realidad.

Un vServer monopuesto no cumple tal requisito por su limitación a un usuario concurrente.

Lo que si se me ocurre una vez que tocaste el tema es que por defecto cuando adquieramos vServers para producción (excepto en la versión vExpress) lo hagamos siempre asignandole un puerto distinto al 690, de esta manera podríamos entonces solicitar un vServer express que funcionará en el puerto 690 e instalarlo en el mismo servidor que el de producción, y sin hacer nada de nada instalar y probar aplicaciones sin la chamba que implica el estarlas copiando.

Muy buen punto, que como todo, la desición final dependerá de muchisimos factores, tanto técnicos, económicos y porqué no decirlo, hasta de gustos personales del desarrollador o el mismisimo cliente.

Saludos.

Martín Ibarra.


([N1] VictorMC) #8

Martín igualmente es un gusto saludarte (preferiría en persona, tu dices cuando) :slight_smile:

Creo entender tu posición, quizá te refieres a que sería bueno utilizar las mismas licencias del vServer en producción, claro está que yo también echo de menos (como dice Manuel) la posibilidad de “guardar como” y listo!

Sin embargo, es lo que se puede hacer con lo que hay.

Saludos cordiales a todos


([N1] Spicer) #9

Amigos,

Muchas gracias por los aportes. Lo de AztecMexico me parece excelente, muchas gracias Martin, siempre con buenas ideas.

¿Alguien ha utilizado la funcionalidad de “Importar Componentes” de vDevelop?
¿Podría crear una nueva solución y luego importar los componentes?

Gracias


([N3] blavan) #10

Por eso te comentaba lo del N1, tu entras en un servidor y con dvelop importas componentes y te trae TODA la solución que tienes ubicada en otro servidor SIN DATOS-
Si la quieres traer con datos entonces tienes que hacer un .vin y despues instalarlo en el nuevo servidor con vadmin