Vamos a actualizar nuestra Política de privacidad próximamente. Te recomendamos consultar el avance.

GitLab esencial

Gestión avanzada de incidencias en GitLab

¡Prueba gratis durante 10 días

nuestros 1288 cursos !

Prueba gratis Mostrar modalidades de suscripción
Cuando empezamos a tener cierto número de incidencias, el caos puede empezar a hacer mella en nuestra gestión. Aprenderemos a utilizar el sistema de etiquetas de GitLab y el cierre automático de incidencias para mantenerlas limpias y organizadas.

Transcripción

Si ya empezamos a estar familiarizados con el gestor de incidencias de Gitlab es necesario que empezemos a realizar un uso más avanzado del mismo. Normalmente solemos gestionarlo con datos muy básicos. Solemos crear un título. Agregar una descripción. Quizá asignárselo a alguien. Y ponerle una fecha límite. Esto está bien cuando tenemos solo un puñado de incidencias pero si empezamos a tener colaboraciones en nuestro proyecto, se empiezan a contar por decenas. La gestión y la administración de las mismas empieza a ser un poco complicado. En este caso hay que empezar a utilizar las etiquetas. Por defecto en los proyectos no hay ninguna etiqueta. Pero si entramos en la sección de etiquetas, en la gestión de nuestro proyecto, está el issues, labels. Veremos que Gitlab nos ofrece crear un conjunto de etiquetas por defecto que son de las más comunes que se utilizan en los proyectos de software. Si generamos un set de etiquetas veremos que nos crea etiquetas para bug, confirmado, critical, discussion, documentation, enhancement suggestion y support. Si veis tienen tendencias a utilizar colores por tipo de etiquetas. Estos son para discusiones y sugerencias. Tenemos los rojos, que son los que están relacionados con bugs. Tenemos los amarillos, que son de documentación. Y el verde, que son de mejora. Es un código de colores que vosotros podeis gestionar , cambiar o adaptar a vuestro flujo de trabajo. Si vamos clasificando nuestros problemas, nuestros issues, con estas etiquetas será muchos más fáciles encontrarlos o acceder a las mismas para poder ir realizándolas. Podríamos decir que agregar menú de selección sería una mejora. O que por ejemplo, no aparece la página los viernes sería un bug. Si por ejemplo este problema con iOS lo hemos estado comentado con los desarrolladores y en efecto el problema está confirmado, podemos asignar dos etiquetas. Tanto bug como confirmado. De esta manera vamos clasificando todas las incidencias que tenemos abiertas y podemos de un vistazo saber cuantas tenemos pendientes, o incluso ir a buscar algún tipo de as en concreto para ir a resolverlas o administrarlas. Si nuestra tarea en el proyecto es muy concreta, por ejemplo, solo estamos intentando buscar errores o solo hacemos mejoras en el software o estamos revisando documentación podemos ir al listado de etiquetas y subscribirnos a una de ellas. Si por ejemplo nos subscribimos a la etiqueta bug, cada vez que alguien agregue una incidencia que tenga esta etiqueta el software nos avisará con una notificación. Si yo creo una nueva incidencia que diga y sin asignársela a nadie le asigno la etiqueta de bug me subscribirá a la misma y me enviará una notificación por correo electrónico. Si revisamos grandes proyectos como el propio poyecto de Gitlab CERN veremos que esto es extremadamente necesario para gestionar tantos miles de incidencias. Si seleccionamos su pestaña de etiquetas vemos que tienen decenas y decenas de ellas clasificadas por colores según el tipo de incidencia. Hay algunas que son de clasificación, por el tipo de incidencia que es si es relativa al Backend a la integración continua, si es documentación, Fronted. Las hay amarillas que son para seleccionar el equipo al que va la incidencia. Las hay verdes relacionadas con analytics. Las hay azules, que se refieren a las piezas del software a las que pertenecen Tenemos autentificación de los factores, api, accesibilidad, páginas de ayuda, importación, etcétera, etcétera. Las hay rojas, que son relativas a las incidencias que son errores. Tenemos este color como azul oscuro que es para grandes tickets que hay que resolver y otros que son de peticiones. Vemos que todo esto se puede conformar según el flujo de trabajo que tengais y como querais clasificarlas. Aparte hay una característica, que es muy interesante, en Gitlab que nos permite cerrar incidencias automáticas cuando creamos algún commit. Si nosotros estamos cerrando incidencias o agregando funcionalidades a través de los commits de nuestro software, podríamos decirle a Gitlab que cada vez que reciba un determinado texto en el commit cierre automáticamente la incidencia que corresponde. Gitlab, para saber que incidencia tiene que cerrar, utiliza una expresión regular que podemos configurar en nuestro fichero gitlab.rb. Si entramos en nuestro servidor y editamos gitlab.rb en la primera página veremos esta expresión regular. Básicamente, porque es un poco compleja, lo que viene a decir es que todos los commits que en el texto incluyan close, closed, closes, fix, fixed, fixes, fixing con un número de incidencia después, Gitlab lo que hará será cerrar esa incidencia automáticamente. Esta es la expresión regular por defecto que tiene Gitlab. Si teneis experiencia en expresiones regulares, si quereis traducirla al castellano o quereis hacer alguna modificación podríais editarlo. Las expresione regualres son una cosa algo compleja, asi que os puedo recomendar que utiliceis la página de Rubular para testear expresiones regulares cambiando la variable, el número de incidencia que es "issue_ref" por un modificador de número de incidencia por un número de varias cifras. Si queremos hacer una prueba y, por ejemplo, cerrar, la incidencia número 5, podríamos ir al proyecto editar un fichero y decir en el mensaje de commit "que... fixes... número 5. Automáticamente Gitlab, leyendo este mensaje de commit, sabrá que este commit cierra la incidencia número 5. Porlo tanto al enviar los cambios, veis que ha bajado en uno nuestro número de incidencias. Si venimos a las incidencias cerradas tenemos este problema de diseño, que era la incidencia número 5 y vemos que el estado ha cambiado por el commit número FE 32215 D, que es el que acabo de hacer yo ahora. Automáticamente queda relacionado el commit con el cierre de la incidencia y aparte se ha cerrado sola lo que permite hacer un seguimiento muy bueno y muy rápido de todos los cambios que hacemos.

GitLab esencial

Aprende a instalar y administrar GitLab, bien en tu propio servidor o en un servicio web gratuito o de pago, y cómo crear un perfil y generar tu primer proyecto en GitLab.

3:14 horas (47 Videos)
Actualmente no hay comentarios.
 
Fecha de publicación:27/10/2016

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.