¿Cuál es la clave para configurar con éxito la entrega continua en proyectos? Trabajo bien coordinado de ingenieros de desarrollo, pruebas e infraestructura. Gracias, cap, como dicen :) Pero, ¿cómo ponerlo en práctica? En este artículo compartiremos nuestras mejores prácticas sobre cómo organizar e implementar todo esto.
Hemos resumido los conceptos básicos en una hoja de trucos para nosotros y compartimos con usted:
Es poco probable que los ingenieros experimentados aprendan algo nuevo del artículo, pero esperamos que esta información sea útil para los principiantes.
¿Cuáles son los requisitos y cómo se caracterizan?
Cada proyecto tiene una serie de requisitos. Es importante comprenderlos a todos y no confundirlos.
Los requisitos comerciales determinan qué debe hacer un sistema desde una perspectiva comercial.
Por ejemplo: la aplicación debería permitir al usuario vender boletos y servicios adicionales para aumentar las ventas de agentes.Los requisitos del usuario describen las metas y objetivos de los usuarios que trabajarán en el sistema para implementar los requisitos del negocio. Los requisitos del usuario a menudo se presentan como casos de usuario.
Por ejemplo: como usuario, necesito vender servicios por millas.Requisitos funcionales : lo que debe hacer el sistema. Determine la funcionalidad (comportamiento) del sistema, que los desarrolladores deben crear para que los usuarios puedan cumplir con los requisitos del usuario.
Requisitos no funcionales : cómo debería funcionar el sistema. Esto incluye requisitos de rendimiento, calidad, limitaciones, usabilidad, etc.
Tipos de tareas y el orden de su descripción en el Rastreador de problemas
Entonces, hemos descrito los tipos de requisitos. Ahora los dividiremos en tipos de tareas, descifraremos cada tipo y diremos cómo describirlo correctamente.
Comencemos con la más épica, es decir, con Epic.
Epic es una tarea común, en la que todas las Historias de usuarios se recopilan teniendo en cuenta el tiempo de desarrollo del servicio. Describe el propósito principal de un producto o servicio. El objetivo principal de Epic es recopilar tareas y almacenarlas en un solo lugar sin importar los nuevos requisitos que se presenten al producto. Epic siempre es más que una historia de usuario y puede que ni siquiera encaje en una iteración.
La solución del problema de Epic le permite crear
MVP (producto mínimo viable), el producto mínimo viable. En otras palabras, lo que se debe publicar para aprender y adaptar el producto en función de los comentarios de los usuarios finales.
¿En qué se diferencia Epic de User Story?
- Epic es solo una gran historia de usuario, cuyo sello distintivo es la presencia de un valor claro para el usuario.
- Comenzando a formar historias de usuarios, es decir, recopilando requisitos para un proyecto, generalmente pasamos de lo general a lo particular: primero determinamos el concepto del proyecto, seleccionamos las personas principales (usuarios del sistema), creamos una lista de las características principales y luego detallamos estas características en deseos separados: Historia del usuario
La descripción de Epic es la siguiente:
- Título / Título de resumen : el nombre de la nueva funcionalidad.
- Descripción / Descripción : se escribe según el patrón:
El rol del usuario (como tal usuario, yo ...) / Acción del usuario (quiero hacer algo ...) / El resultado de la acción (para obtener tal resultado que ...) / Interés o beneficio (me permitirá obtener tales y tales beneficios ...). - Un plan de implementación de muestra o una breve descripción de las Historias de usuarios principales que se implementarán como parte de Epic con MVP.
- Adjuntos / Adjuntos : adjunte correspondencia, tecnología y otra información necesaria.
Cómo hacer una historia de usuario y una historia tecnológica
La diferencia entre User story y Tech story es que Tech Story se refiere a requisitos funcionales que deben tenerse en cuenta y describirse en la tarea al desarrollar el producto. Y en el papel de los consumidores aquí hay partes del sistema.
Describirlos es fácil. Lo principal para recordar es por qué se está haciendo todo esto.
El orden de descripción de la historia del usuario es bastante estándar:
- Título / Resumen / Título: una breve descripción de la nueva funcionalidad o mejoras en un idioma que el cliente pueda entender.
- Descripción / Descripción incluye el objetivo principal y el resultado deseado. Al igual que, <rol de usuario>, <quiero obtener>, con el objetivo de <resultado de acciones>.
- Los criterios de aceptación son una lista de criterios de producto prioritarios. Es decir, una definición medible de lo que debe hacerse con el producto para que sea aceptado por los interesados del proyecto.
- Notas técnicas, modelos, diseños, diseños de página.
- Adjuntos / Adjuntos: todas las tecnologías necesarias, documentos, correspondencia con el cliente.
Cómo describir errores
Qué información se debe indicar al informar un error:
1.
Título / Resumen / Título describe brevemente la esencia del error e indica la ubicación del problema.
2. La descripción contiene los siguientes pasos:
• cómo reproducir los pasos de error / reproducción,
• resultado actual,
• resultado esperado.
3.
Adjuntos / Adjuntos : todos los registros necesarios, capturas de pantalla, enlaces a Kibana y otros archivos.
4.
Entorno : una marca en qué entorno se reproduce el error y la categoría a la que pertenece el problema. Por ejemplo, un error de UI, error CORE, error SWS, etc.
5. La
prioridad permitirá que cada miembro del equipo evalúe la gravedad del problema y que el gerente lo vea en la lista de primeros candidatos para el sprint.
Y no olvide establecer el nivel de prioridad correcto :)
Ahora que hemos entendido los principios generales del trabajo, le diremos cómo organizar el proceso de implementación.
Configuración de canalización de implementación
Para acelerar la entrega de nuestros servicios a la producción, presentamos una nueva tubería de implementación y utilizamos GitFlow para trabajar con el código.
Para hacer esto de forma rápida y dinámica, implementamos varios corredores de GitLab que ejecutaban todas las tareas push de los desarrolladores. Gracias al enfoque de GitLab Flow, tenemos varios servidores: desarrollo, control de calidad, lanzamiento-candidato y producción.
La integración continua comenzó a recopilar y ejecutar pruebas para cada confirmación, ejecutar pruebas unitarias y pruebas de integración, agregar artefactos a la entrega de la aplicación.
El desarrollo tiene lugar así:
- El desarrollador agrega nueva funcionalidad en una rama separada (rama de características). Después de eso, crea una solicitud para fusionar su rama con la rama principal de desarrollo (Solicitud de fusión para desarrollar rama).
- Otros desarrolladores miran la solicitud de fusión, la aceptan (o no) y corrigen los comentarios. Después de la fusión, se desarrolla un entorno especial en la rama del tronco, en el que se realizan pruebas para elevar el entorno.
- Cuando se completan todos estos pasos, el ingeniero de control de calidad lleva los cambios a su rama "QA" y realiza las pruebas.
- Si el ingeniero de control de calidad está de acuerdo con el trabajo realizado, los cambios van a la rama Release-Candidate y se implementan en un entorno accesible para los usuarios externos. En este entorno, el cliente acepta y verifica tecnologías. Luego destilamos todo en Producción.
Si en algún momento hay errores, entonces es en esta rama donde los resolvemos, después de lo cual publicamos el resultado en Desarrollar.
También creamos un pequeño complemento para que Redmine pueda decirnos en qué etapa se encuentra la función. Esto ayuda a los evaluadores a evaluar en qué etapa necesita conectarse a la tarea y a los desarrolladores a corregir los errores. Entonces, ven en qué etapa ocurrió la falla, pueden ir a una rama específica y reproducirla allí.
Esperamos que lo encuentre útil.