Contributing proposal

[davidromani]

Hola.

Veo que cada issue lleva su ritmo y, con el modelo de workflow que usamos, pronto nos vamos a encontrar con problemas a la hora de subir código a producción. Si seguimos así nos encontraremos con código en devel listo para subir y código pendiente de finalizar.

Con el fin de solucionar este problema y poder subir (de forma independiente) código a producción os propongo que usemos este esquema.

La idea básica és añadir una nueva rama "stagging" que estaria sincronizada con el servidor de pruebas (subdominio plataforma2) y abrir una rama por issue (o feature). De esta forma podemos aislar el desarrollo y subir primero estas ramas "feature/..." a "stagging" para probar. Después, cuando esté testeada y finalizada, podremos mergear la misma rama "feature/..." (otra vez) contra la rama "devel".

El código de la rama "devel" y "master" estaria sincronizado con el servidor de producción (subdominio plataforma). Creo que con esta idea podremos avanzar el despliegue en producción de las issues terminadas.

Que os parece? @pablovg2 @pr3ssh @BLACKLEG @francesccasadella

[hectorespert]

Por mi bien.

[pr3ssh]

@davidromani Por mi ok también. En este sentido... para que sirve tener devel y master si serán iguales? Usaremos este esquema sin git-flow verdad? Creo que el esquema es bueno pero por ahora no lo complicaría más.

[francesccasadella]

adelante, con muchas ganas de ver los primeros issues subidos a máster :)

[davidromani]

Ok, entonces ya podemos comenzar con este sistema.

Un detalle, las ramas de desarrollo en lugar de poner "feature/<issue_#>", para que la gente lo entienda mejor poner "issue/<issue_#>"

@BLACKLEG @pablovg2 @pr3ssh

[pr3ssh]

@davidromani Si tienen los fuentes de la imagen... podrías editarla para que nos valga como documentación y asi no creemos ramas con otro nombre dentro de 3 meses? Gracias.

[hectorespert]

@Som-Energia/plataforma Y si usamos git-flow directamente?

Tendríamos la posibilidad de hacer hotfix, la rama devel no seria solo una copia de master como indica @pr3ssh y es un poco como un estándar.

Las ramas feature podrían ser issue y las ramas release serian las que se probarían en plataforma2.

Una variación podría ser que la rama stagging hiciera la función de las ramas release.

• Las features una vez finalizadas se mergean a devel.
• Para hacer un "release" mergeamos devel con stagging y se prueba esta rama en plataforma2.
• Una vez probado y corregidos los errores, se mergea stagging con master para subirlo a la plataforma y se mergea también con devel para añadir los cambios realizados.