Simular estados Stable/Testing/Development en soluciones

Velneo
1

Hola a todos,

En mi nube, para distintos proyectos, quiero, para una misma solución, distinguir entre versión estable, versión testing, y versión actual de desarrollo.

Mi intención, es, de la manera más cómoda posible, estar trabajando en el proyecto (versión development), para llegado un determinado momento, pasarlo a testing, y llegado el momento pasarlo a Stable, pero obviamente, no quiero que la parte de desarrollo, se refleje en la estable ni testing, hasta que yo, específicamente "lo mueva".

Se podría hacer con distintas instancias, pero hasta donde creo, el problema viene, que al reiniciar el vServer (o si por alguna extraña razón se reinician las instancias), entonces se actualizaría con los últimos cambios.

Se os ocurre alguna manera lo más cómoda posible de obtener algo así?

Espero haberme explicado.

Nota: La idea es hacerlo todo en el mismo vServer

2

Hola.

Que yo sepa, no hay ningún modo "cómodo" de realizar lo que quieres. Y si me apuras, tampoco "incómodo".

Además, como en Velneo está todo centrado en la solución, y como no es posible separar adecuadamente una solución modificada en desarrollo de la solución que está en una instancia (efectivamente, al reiniciar el servidor tomaría los últimos cambios), te tienes que buscar la vida de otra manera.

Al menos en mi esquema de trabajo, lo que hago es:

- Ultima versión estable: la que tiene el cliente, en su servidor (sea en la nube -la mía-, sea local a su oficina)
- Versión en desarrollo: la que tengo en mi servidor en la oficina
- Versión en testing: cuando es necesario, subo la solución a mi servidor en la nube de Velneo, para que el cliente pueda ver los cambios significativos, o probar nuevas funcionalidades. O bien, la instalo en el servidor local de mi equipo (diferente del servidor de desarrollo de la oficina).

Con esto, mantienes la unicidad de la solución, pero no del vServer. No he contestado a tu pregunta para nada, pero al menos te muestro cómo intento solucionar ese problema.

Saludos,

Fran Varona

3

Hola Giuseppe,

Hay que ver que fashion ;) stable-testing-development, me mola tu estilo, corres el riesgo de que te lo copie :)
Bromas a parte, si los desarrollos los haces todos en local, no tengo muchas ideas al respecto. Pero ¿has pensado en utilizar vServer's distitos en la nube?
Por ejemplo,
el testing - en la nube con un N1 gratuito [clon 1]
el stable - en la nube con otro N1 gratuito [clon 2]
el develop - en local con tu N2 [Giuseppe]
Cuando te parezca que tienes cualquiera maduro lo instalas en el siguiente estado, y a rodar. No se si eso satisface tu impecable planificación de software ;)
Un abrazo.
Un saludo

4

@ikonos

El problema de tu solución, es, que yo necesito distinguir soluciones completas, y a los servers N1 no puedes tirar de vinstallbuilder, ni importar con vdevelop creo.

luego me extiendo, que estoy desde el movil

5

Hay que ver que fashion stable-testing-development, me mola tu estilo, corres el riesgo de que te lo copie

Tranqui, mi contenido es copyleft :)

Bromas a parte, si los desarrollos los haces todos en local, no tengo muchas ideas al respecto. Pero ¿has pensado en utilizar vServer's distitos en la nube?
Por ejemplo,
el testing - en la nube con un N1 gratuito [clon 1]
el stable - en la nube con otro N1 gratuito [clon 2]
el develop - en local con tu N2 [Giuseppe]

Para mi, el vServer de la nube y el local "deben ser el mismo". Yo sólo uso el local (que lo tengo en el portátil) cuando voy a estar desenganchado de internet.

Los problemas de usar vServers N1, en mi opinión son:
1.- A los servidores N1, no puede engancharse vInstallBuilder, además, que, hasta donde recuerdo, tampoco permiten importar componentes (y si lo permiten, no deberían).
2.- Estoy gastando recursos de Velneo (cosa que no quiero hacer), y haciendo algo "ilegal", porque para eso se venden las licencias de edición extras.
3.- GOTO 1

Realmente, el entorno que quiero montar (por si te interesa los nombres cool :P ) es el siguiente:
Un proyecto, tendría 4 soluciones distintas e independientes.

Development: La rama principal donde se van haciendo todos los cambios. Según se van implementado mejoras/ideas/bugs, pasan a Testing.
Testing: Para ir probando en "producción" los cambios de la versión Development. Cuando estos cambios son estables, pasan a Frezee.
Freeze: Código congelado que no debe modificarse por motivos de ideas, sólo bugs. A esta rama, vienen los módulos ya finalizados. Versión candidata a ser la siguiente versión Estable una vez se encuentre todas las cajas actualizadas a la versión que deben.
Stable: Solución final. Sólo modificable para resolución de bugs.

Resumiendo, tu solución es la viable, pero necesitaría 4 servidores de edición.

Ahora mismo, sin pensarlo demasiado, sólo se me ocurre cambiando el nombre de las cajas, y copíandolas y pegándolas y renombrando, pero..hasta donde creo, no se puede copiar y pegar una caja completa.

6

Hola Guiseppe;

Yo me he estado haciendo la misma pregunta hace ya un rato .... mi una conclusión => vServer local +Git tendría tres ramas en el Repo y me moveria entre ellas para ir trabajando en cada caso, en lo que al vServer refiere para el la solución sera el commit donde este el Head,

No se solo es una idea a la que le ando dando vuelta pero no la he testeado.

Saludos,

7

@Giuseppe,

Muy cool, muy cool ;) pero deberiamos añadir los siguientes estados,

el "casual development"
el "deadlock develolopment"
el "black hole development"
el "mode freaky development"
y mi preferido :) "$table cash flow development $$$"

pero en fin, aunque no los incluyas en tu PaaS cuando encuentres una buena solución practica a tu hilo, publica por que está muy bien pensado y estructurado.

Un saludo.