Diferencia entre revisiones de «Autenticacion»
De Wiki de EGC
(→Hoja de tiempo) |
|||
| (No se muestra una edición intermedia de otro usuario) | |||
| Línea 34: | Línea 34: | ||
La documentación se encuentra disponible en el siguiente [http://auth-egc.azurewebsites.net/Help enlace] | La documentación se encuentra disponible en el siguiente [http://auth-egc.azurewebsites.net/Help enlace] | ||
| − | == | + | == Gestión de incidencias == |
| − | + | Para la gestión de incidencias usamos la herramienta de gestión de incidencias de Gitlab. | |
| + | El modo de operación es el siguiente: | ||
| + | * Una persona identifica una incidencia/cambio, ya sea externa o un desarrollador y la registra en nuestro sistema, Gitlab. | ||
| + | * El administrador del repositorio, Álvaro Rojas, recibe un correo que indica que se ha creado una nueva incidencia. | ||
| + | * El administrador del repositorio revisa la incidencia, en el caso de que la incidencia no sea correcta, la marca como rejected, escribe un comentario de porqué se ha rechazado si fuese necesario, la cierra y lo notifica. En caso de que sea correcta, el administrador asigna la incidencia a un desarrollador en base al número de incidencias abiertas que tenga asignadas. | ||
| + | * El sistema notifica al desarrollador que debe subsanar esa incidencia. | ||
| + | * Si es necesario el desarrollador escribe un comentario sobre la incidencia. | ||
| + | * El desarrollador asignado puede también rechazar la incidencia si finalmente esta no es necesaria y cerrarla. | ||
| + | * Cuando el desarrollador subsana la incidencia, realiza un pull request a la rama maestra, el administrador del repositorio recibe un correo indicando que tiene un pull request pendiente, el administrador revisa el código de la petición y si es correcto, acepta la request y realiza el merge en la rama maestra, con lo que se cierra la incidencia. | ||
| + | Estados por los que pasa una incidencia: | ||
| + | * Open: está abierta. | ||
| + | * Ongoing: está abierta y asignada. | ||
| + | * Closed: ha sido cerrada. | ||
| + | Etiquetas que se pueden asignar a una incidencia: | ||
| + | * Critical: Esa incidencia debe ser resuelta lo antes posible. | ||
| + | * Enhancement: Esa incidencia implica una mejora de la funcionalidad del sistema. | ||
| + | * Documentation: Esa incidencia implica documentar el contenido del sistema. | ||
| + | * Bug: Esa incidencia implica el arreglo de un fallo. | ||
| + | * Rejected: La incidencia ha sido rechazada. | ||
| + | Solo se rechazarán incidencias que no tengan que ver con nuestro sistema o que sean incorrectas/duplicadas. | ||
| + | La prioridad de los cambios se ordena de la siguiente manera: | ||
| + | 1. Critical. | ||
| + | 2. Bug. | ||
| + | 3. Enhancement. | ||
| + | 4. Documentation. | ||
Revisión actual del 11:58 31 ene 2016
Contenido
Miembros
Definición
Un subsistema de AGORA@US para autenticar usuarios. Este subsistema es una api en la cual los demás subsistemas podrán hacer peticiones de autenticación y verificación de los usuarios del sistema AGORA@US.
Actas de reunión
- Taller 1 : Planificación de la gestión del proyecto
- Taller 2 : Definición de los cambios a realizar
- Taller 3 : Primer taller de integración
- Taller 4 : Segundo taller de integración
- Taller 5 : Tercer taller de integración
- Taller 6 : Cuarto taller de integración
Repositorio de código
Nuestro repositorio de git está alojado en gitlab.
Los usuarios interesados en crear issues sobre nuestro subsistema podran hacerlo en dicho repositorio.
Aplicación en producción
La aplicación está desplegada en la plataforma Microsoft Azure mediante integración contínua, en el siguiente enlace.
Código heredado
Errores en el código heredado:
- Se ha detectado que en las funciones parametrizadas de la api del código heredado, cuando no se introduce el param sigue dando un json cuando debería disparar un error 400 bad request.
Documentación
La documentación se encuentra disponible en el siguiente enlace
Gestión de incidencias
Para la gestión de incidencias usamos la herramienta de gestión de incidencias de Gitlab. El modo de operación es el siguiente:
- Una persona identifica una incidencia/cambio, ya sea externa o un desarrollador y la registra en nuestro sistema, Gitlab.
- El administrador del repositorio, Álvaro Rojas, recibe un correo que indica que se ha creado una nueva incidencia.
- El administrador del repositorio revisa la incidencia, en el caso de que la incidencia no sea correcta, la marca como rejected, escribe un comentario de porqué se ha rechazado si fuese necesario, la cierra y lo notifica. En caso de que sea correcta, el administrador asigna la incidencia a un desarrollador en base al número de incidencias abiertas que tenga asignadas.
- El sistema notifica al desarrollador que debe subsanar esa incidencia.
- Si es necesario el desarrollador escribe un comentario sobre la incidencia.
- El desarrollador asignado puede también rechazar la incidencia si finalmente esta no es necesaria y cerrarla.
- Cuando el desarrollador subsana la incidencia, realiza un pull request a la rama maestra, el administrador del repositorio recibe un correo indicando que tiene un pull request pendiente, el administrador revisa el código de la petición y si es correcto, acepta la request y realiza el merge en la rama maestra, con lo que se cierra la incidencia.
Estados por los que pasa una incidencia:
- Open: está abierta.
- Ongoing: está abierta y asignada.
- Closed: ha sido cerrada.
Etiquetas que se pueden asignar a una incidencia:
- Critical: Esa incidencia debe ser resuelta lo antes posible.
- Enhancement: Esa incidencia implica una mejora de la funcionalidad del sistema.
- Documentation: Esa incidencia implica documentar el contenido del sistema.
- Bug: Esa incidencia implica el arreglo de un fallo.
- Rejected: La incidencia ha sido rechazada.
Solo se rechazarán incidencias que no tengan que ver con nuestro sistema o que sean incorrectas/duplicadas. La prioridad de los cambios se ordena de la siguiente manera: 1. Critical. 2. Bug. 3. Enhancement. 4. Documentation.
