Diferencia entre revisiones de «Iterable 3 (27/10/14)»
De Wiki de EGC
(Página creada con «==Asistentes== {| border="1" style="border-collapse:collapse;text-align:center" class="wikitable" |- ! Asistió ! Miembro del grupo |- | ✓ | David Álvarez Silva |- | ...») |
(→Resultado) |
||
| (No se muestran 2 ediciones intermedias del mismo usuario) | |||
| Línea 33: | Línea 33: | ||
==Resultado== | ==Resultado== | ||
| − | + | En cuanto a la gestión del código, concretamente a la gestión de ramas, se han tomado las siguientes decisiones: | |
| − | * | + | * 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. |
| − | * | + | * Una vez establecida la rama principal, 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. Cada branche se corresponderá con una funcionalidad diferente, o bien con una rama sobre la que se realizarán pruebas. |
| − | * | + | * 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 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. | + | * 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. | ||
Revisión actual del 17:16 3 nov 2014
Asistentes
| 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 cuanto a la gestión del código, concretamente a la gestión de ramas, se han tomado las siguientes decisiones:
- 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.
- Una vez establecida la rama principal, 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. Cada branche se corresponderá con una funcionalidad diferente, o bien con una rama sobre la que se realizarán pruebas.
- 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, 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.
