Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Gestión SVN

No description
by

Juan Fran Arévalo

on 14 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Gestión SVN

Puede ocasionar problemas en la integración
Branch
(catalog-2.3.x)
Pre
Se bajan cambios
2.2.2
GESTIÓN SVN
Cómo aprender mejor?
Problemas
Desconocimiento de la Metodología:
Ramas de Desarrollo
vs
Ramas de Deploy
Piano Piano...
TRUNK:
Línea principal de desarrollo, es donde se integrarán todos los desarrollos del proyecto.
... se va lontano
Branch Despliegue:
Branch que se ha creado para el proceso de despliegue. Puede ser una rama de PRE o de PRO.
Caso 1
Se necesita realizar un bugfixing sobre una aplicación en producción.
Caso

Se encuentran bugs en la versión que se quiere subir a Producción durante las pruebas en el entorno de PRE
Caso 3
Tras testear el nuevo desarrollo en PRE, se aprueba para subir a PRO
Caso 4
Finalizado el desarrollo de un proyecto se quieren subir a PRE las nuevas "
features
":
Problema 1
¿Qué ocurre si un bug corregido en la rama de PRO no se baja hasta Trunk?
Problema 2
Una rama de desarrollo integrada en Trunk, está inactiva, y no se debe subir código a ella.
Problema 3
No mergear a lo largo de todo el proyecto, y aguardar a la integración en Trunk es una práctica habitual:
O CÓMO HACERNOS LA VIDA MUCHO MÁS SENCILLA
Trunk
@jfranarevalo / @rtve
WTF!!!!
Problemática Actual
¿Donde he de subir mis cambios? Trunk, 2.6.x, 2.6.0 ...
Merge de Integración
vs
Merge de Desarrollo
Por dónde Empezamos?
"- ¿Por dónde debo empezar, con la venia de Su Majestad? - preguntó el Conejo Blanco.
Alicia en el País de las Maravillas
- Empieza por el principio -dijo el Rey con gravedad- y sigue hasta llegar al final;
allí te paras."
BRANCHs:
Se utilizan para separar desde un punto concreto de Trunk desarrollos en paralelo
TAGs:
Se genera un tag cada vez que se genera una versión de subida
Branch Desarrollo:
Branch que se crea cada vez que se quiere iniciar un nuevo desarrollo en paralelo.
js-2.2.x
js-2.1.x
2.2.0
2.2.1
CON EJEMPLOS
"Caminante, no hay camino,
se hace camino al andar"
Antonio Machado
BUG EN PRODUCCIÓN
Se ha de tener una imagen del estado en producción
El bugfixing se realiza sobre esa imagen
Se genera nueva release y se despliega en producción
TESTING
EN PRE
Se ha de mantener el estado del desarrollo que se quiere subir a PRO
El bug detectado durante las pruebas se arregla sobre esa imagen
Branch
(catalog-2.2.x)
TAG 2.2.1
Se añade Swype al listado
Se permite gestionar el texto a mostrar
Trunk
(catalog)
Branch
(catalog-2.2.x)
TAG 2.2.1
Se añade Swype al listado
Se permite gestionar el texto a mostrar
Trunk
(catalog)
Deploy
Branch
(catalog-2.3.x-releche)
Develop
Branch
(catalog-2.2.x)
Trunk
(catalog)
Pro
Branch
(catalog-2.3.x-releche)
Develop
2.2.1
2.2.2
A producción
2
Pro Branch
(catalog-2.2.x)
Trunk
(catalog)
Branch
(catalog-2.3.x-releche)
Develop
2.2.1
2.2.2
Branch
(catalog-2.3.x)
Pre
2.3.0
2.3.1
SUBIDA A PRODUCCIÓN
La release de PRE es la que sube a PRO
La imagen que hasta ahora se ha probado en PRE, es la que pasa a ser la imagen de PRO
Pro Branch
(catalog-2.2.x)
Trunk
(catalog)
Branch
(catalog-2.3.x-releche)
Develop
2.2.1
2.2.2
Branch
(catalog-2.3.x)
Pre
2.3.0
2.3.1
Trunk
(catalog)
Branch
(catalog-2.3.x-releche)
Develop
Branch
(catalog-2.3.x)
Pro
2.3.0
2.3.1
A producción
A pre
A pre
Se bajan cambios
Se bajan cambios
SUBIDA DE DESARROLLO A PRE
Dado que va a subir a PRE se genera una rama para mantener el estado de PRE
Se pasa a inactiva la rama de desarrollo
Se genera la primera release para la subida a PRE
Pro Branch
(catalog-2.3.x)
Develop Branch
(catalog-2.3.x-releche)
2.3.0
2.3.1
Pre Branch
(catalog-2.4.x)
2.4.0
Se debe integrar el desarrollo en Trunk
Trunk
(catalog)
Integramos
A pre
Caso 5
Durante todo el desarrollo de un nuevo proyecto hay cambios en la línea base del mismo:
INTEGRACIÓN DURANTE
EL DESARROLLO
Dejar la integración para final, puede retrasar el proyecto
Integraciones continuas disminuyen la complejidad
Favorece encontrar errores más temprano
Trunk

(catalog)
Develop Branch
(catalog-2.3.x-releche)
Se bajan cambios
Se bajan cambios
Integración
Integración
Integración
Se bajan cambios
Integración
Caso 6
En ocasiones en PRE conviven varios desarrollos que se van a poner en producción a la vez.
CAIDA DE DESARROLLO ANTES DE SUBIR
"Si no eres parte de la solución, eres parte del problema, actúa!"
Lenin
Uno de ellos se puede caer por que deba ser aprobado para subir (Contenidos, Comercial...)
Hay que valorar que supone más coste:
Realizar rollback del desarrollo que se cae en PRE
Actualmente no disponemos de entornos infinitos
Subir el desarrollo a la rama de
PRO
Pro Branch
(catalog-2.3.x)
Trunk
(catalog)
Develop Branch 1
2.3.0
2.3.1
Pre Branch
(catalog-2.4.x)
2.4.0
2.4.1
A pre
A pre


Develop Branch 2
Rollback integración
Branch 2
Develop
Bug no bajado hasta Trunk
Subir a ramas inactivas
No mergear durante el
desarrollo
Cuando suba el desarrollo de PRE, se perderá la corrección.
Todo nuevo proyecto que se integre no tendrá probado el cambio en su desarrollo.
Las ramas de desarrollo creadas tampoco llevarán el cambio.
Pro Branch
(catalog-2.2.x)
Trunk
(catalog)
Branch
(catalog-2.3.x-releche)
Develop
2.2.1
2.2.2
Branch
(catalog-2.3.x)
Pre
2.3.0
A pre
Se arregla Bug en
carga de imágenes
Es común, al arreglar un bug en PRE, que se suba el cambio a la rama de desarrollo:
Se puede subir a PRE de nuevo sin haber corregido el problema.
La integración de esos cambios desde la rama inactiva puede dar problemas
Supone una pérdida de tiempo
Pro Branch
(catalog-2.3.x)
Develop Branch
(catalog-2.3.x-releche)
2.3.0
2.3.1
Pre Branch
(catalog-2.4.x)
2.4.0
Trunk
(catalog)
Integramos
A pre

Subir a PRE!!
2.4.1
A pre
Sigue
fallando...
Subida cambios
Problema 5
Subir a Trunk desarrollos no aprobados
Problema 4
Cambiar versiones de pom
Subido un desarrollo, los equipos pueden hacer nuevos cambios dentro del mismo proyecto.
Es común, que esos nuevos desarrollos sin probar los suban a ramas oficiales (Trunk, PRE, PRO):
Se puede subir a PRE/PRO un desarrollo no probado.
Cualquier nueva rama de desarrollo llevará el cambio incompleto.
Puede crear conflictos con un desarrollo aprobado.
Volvemos a perder tiempo todos
Pro Branch
(catalog-2.2.x)
Trunk
(catalog)
2.2.1
2.3.0
2.3.1
Nuevo evolutivo
¿donde lo subo?
Subida gestión
de imagénes
2.3.2
Branch
(catalog-2.4.x-infantil)
Develop
La corrección de un
nuevo bug se lleva
los cambios de
gestión de imágenes
Hay que probar de nuevo todo
Los errores cuanto antes, mejor
Para agilizar desarrollos se suelen cambiar versiones de pom.
Fase de desarrollo:
Se modifica y se trabaja sobre una versión de producción como si fuera una de desarrollo.
NO
tiene últimos cambios
NO
se prueba el escenario real
En rama de despliegue:
Se cambian versiones a snapshot
Se gana en
rapidez
Subirlas a la rama
es un error
Se puede generar
release incorrecta
js-2.0.x
2.2.3
2.2.4
2.0.0
2.0.1
2.0.2
2.1.0
2.1.1
2.1.5
2.1.2
2.1.3
2.1.4
olvido
Enséñame
y lo

recuerdo
Involúcrame
aprendo
y
Dime
y lo
Las reglas del juego son sencillas
Conclusiones...
Organizar la subida de código permite automatizar cosas
El 90% de los casos se resuelve con lo que hemos visto. Para el resto
preguntar
No seguir esta metodología conlleva problemas y pérdida de tiempo
GRACIAS!!!
Full transcript