Iterable 3 (27/10/14) - Historial de revisiones

Fradelval: /* Resultado */

2014-11-03T16:16:01Z

‎Resultado

Fradelval: /* Resultado */

2014-11-03T16:14:52Z

‎Resultado

Fradelval: /* Resultado */

2014-11-03T16:02:06Z

‎Resultado

Fradelval: Página creada con «==Asistentes== {| border="1" style="border-collapse:collapse;text-align:center" class="wikitable" |- ! Asistió ! Miembro del grupo |- | ✓ | David Álvarez Silva |- | ...»

2014-11-03T16:01:30Z

Página creada con «==Asistentes== {| border="1" style="border-collapse:collapse;text-align:center" class="wikitable" |- ! Asistió ! Miembro del grupo |- | ✓ | David Álvarez Silva |- | ...»

Página nueva

==Asistentes==

{| border="1" style="border-collapse:collapse;text-align:center" class="wikitable"
|-
! Asistió
! Miembro del grupo
|-
| ✓
| David Álvarez Silva
|-
| ✓
| Antonio Juan Amador Salmerón
|-
| ✓
| Francisco Javier Delgado Vallano
|-
| ✓
| Guiomar Fernandez de Bobadilla Brioso
|-
| ✓
| Jose Luis García Mora
|-
|
| Sebastián Garrocho Capacete
|-
|
| Javier Guisado Torres
|-
|
| Rafael Quesada García
|}

==Resultado==

** En primer lugar, el administrador del repositorio establece un root branch o rama principal, que será la baseline del proyecto; a partir del cual se va a realizar el desarrollo del mismo.

** Una vez establecido esto, el administrador puede abrir varios branches o ramas en las que se pueden ir desarrollando nuevas funcionalidades paralelamente. Éstos branches serán asignados a diferentes integrantes del grupo a los que se les asignará los permisos correspondientes, ya sea de lectura, escritura o ambos.

** El motivo de crear ramas es el de agilizar el trabajo con el reparto del mismo, de modo que partiendo de la baseline se vayan añadiendo, modificando o probando nuevas funcionalidades.

** La ventaja de esto, esta en que si al desarrollar el branch asignado se encuentra con un error o no puede continuar con el desarrollo, puede volver a la versión almacenada en el root branch. Además de esto, es muy útil a la hora de realizar pruebas, ya que se abre una nueva rama en la que se realizarán las pruebas, mientras que el root branch sigue estable.

** En nuestro caso, todos los usuarios contarán con los permisos tanto de lectura como de escritura.
Las ramas serán creadas con una fecha límite, la cual se corresponde con la fecha establecida en el Sprint correspondiente, por lo que antes de la finalización de dicho plazo el desarrollo a llevar a cabo debería ser completado y por tanto probado para realizar posteriormente un merge.
Los merges, es decir, la integración de las nuevas funcionalidades con la rama principal, de modo que dicha rama tendría una nueva versión.

** En el caso de la integración del código con otros subsistemas o merges, solo se realizarán en el caso de que dichos subsistemas sean totalmente estables.

@@ Línea 46: / Línea 46: @@
 * Las ramas serán creadas con una fecha límite, la cual se corresponde con la fecha establecida en el Sprint correspondiente, por lo que antes de la finalización de dicho plazo el desarrollo a llevar a cabo debería ser completado y por tanto probado para realizar posteriormente un merge.
 Los merges, es decir, la integración de las nuevas funcionalidades con la rama principal, de modo que dicha rama tendría una nueva versión.
 * En el caso de la integración del código con otros subsistemas o merges, solo se realizarán en el caso de que dichos subsistemas sean totalmente estables.

@@ Línea 33: / Línea 33: @@
 ==Resultado==
-* En primer lugar, el administrador del repositorio establece un root branch o rama principal, que será la baseline del proyecto; a partir del cual se va a realizar el desarrollo del mismo.
+En cuanto a la gestión del código, concretamente a la gestión de ramas, se han tomado las siguientes decisiones:
-* Una vez establecido esto, el administrador puede abrir varios branches o ramas en las que se pueden ir desarrollando nuevas funcionalidades paralelamente. Éstos branches serán asignados a diferentes integrantes del grupo a los que se les asignará los permisos correspondientes, ya sea de lectura, escritura o ambos.
+* En primer lugar, el administrador del repositorio establecerá un root branch o rama principal, que será la baseline del proyecto; a partir del cual se va a realizar el desarrollo del mismo.
 * El motivo de crear ramas es el de agilizar el trabajo con el reparto del mismo, de modo que partiendo de la baseline se vayan añadiendo, modificando o probando nuevas funcionalidades.
@@ Línea 41: / Línea 43: @@
 * La ventaja de esto, esta en que si al desarrollar el branch asignado se encuentra con un error o no puede continuar con el desarrollo, puede volver a la versión almacenada en el root branch. Además de esto, es muy útil a la hora de realizar pruebas, ya que se abre una nueva rama en la que se realizarán las pruebas, mientras que el root branch sigue estable.
-* En nuestro caso, todos los usuarios contarán con los permisos tanto de lectura como de escritura.
+* En nuestro caso, todos los usuarios contarán con los permisos tanto de lectura como de escritura, además al tratarse de una funcionalidad pequeña serán pocas las ramas que se utilicen.
 Las ramas serán creadas con una fecha límite, la cual se corresponde con la fecha establecida en el Sprint correspondiente, por lo que antes de la finalización de dicho plazo el desarrollo a llevar a cabo debería ser completado y por tanto probado para realizar posteriormente un merge.
 Los merges, es decir, la integración de las nuevas funcionalidades con la rama principal, de modo que dicha rama tendría una nueva versión.
 * En el caso de la integración del código con otros subsistemas o merges, solo se realizarán en el caso de que dichos subsistemas sean totalmente estables.