Garantía de calidad del software¶
La última etapa del desarrollo por parte de desarrollador, es verificar los siguientes puntos para dar por terminado la modificación y pasar a la inclusión del código a la rama estable o en desarrollo. La ausencia de algún punto podría desencadenar un problema con el desarrollo o la falta de descripción del mismo proyecto.
Estandáres de código¶
La verificación de los estandáres de código es importante seguirla desde el comienzo de nuestras modificaciones. Cada repositorio tiene ciertos estandáres que deben de seguir los desarrolladores para que la lectura sea lo más homogénea posible. Así cualquier desarrollador se sentirá cómodo al recorrer el proyecto y las modificaciones las llevará a cabo en menor tiempo.
Prueba de los cambios localmente¶
Este paso es de ayuda para correr los cambios lo más aisladamente posible y que no interfieran con módulos en producción. Los cambios realizados en el ciclo de desarrollo pueden crear conflictos si están conectados con módulos reales o con herramientas externas que se usen en producción. Es por eso que la verificación de este punto es vital para mantener a salvo los datos de los clientes que actualmente están usando los proyectos.
Pruebas unitarias y de integración¶
Cada una de las pruebas que se han generado a partir del código que hemos modifcado o agregado, deben de ser ejecutadas e integradas a la recopilación de pruebas automáticas del proyecto. La ejecución manualmente nos da certeza que nuestro código ha cumplido todas las características del diseño y agregarlas a las pruebas automáticas nos mantendrá atentos a errores futuros.
Documentación¶
En cuestión de documentación no todos los cambios se necesitan agregar a sus diferentes tipos. Mediante una evaluación rápida podemos deducir cuales son las ediciones que se harán. Si las modificaciones al código cambiaron al menos un poco el comportamiento de una función es necesario hacer la edición de su documentación para que el generador automático agregue los cambios. Esta es la edición de la documentación que sea más probable tener. Si las modificaciones son más hacia el comportamiento de la aplicación en general, como el agregar una nueva característica o hacerla obsoleta, sí se debería de cambiar la documentación del usuario o del desarrollador.
Changelog y versionado¶
En cada uno de los repositorios de The Robox habrá o está pensado que haya un documento
llamado CHANGELOG.md. Este es el registro de los cambios que se han hecho a lo
largo del proyecto. Aquí agregaremos cada cambio que se ha hecho al repositorio, esto
quiere decir que si nuestra tarea fue arreglar un bug que tenía el proyecto, editaremos
el archivo con una línea muy breve pero descriptiva de lo que hemos arreglado.
La manera de editarlo sería la siguiente:
# Project Change Log
Breve texto de descripción del archivo
* Nueva línea de los cambios que se hicieron antes de ser aprobado
tu merge request ([#1234](link externo))
* Algún cambio ya aprobado tuyo o de otro desarrollador
## Número de la última versión estable o aprobada para uso (Fecha)
* Algún Cambio de la última versión
* Algún Cambio de la última versión
* Algún Cambio de la última versión
Se agregará la nueva línea entre la descripción del archivo o el título de este y el último cambio aprobado o el subtítulo de la última versión estable.
El texto será una frase en inglés que describa lo mejor posible lo que se realizó. Esto quiere decir que se decriba si se agregó, cambió, removió o ahora se encuentra obsoleta una característica del software.
Opcionalmente pero sería de mucha ayuda, agregar al final el link del issue relacionado a esta mejora.
Usa todo el poder de markdown a tu beneficio para describir mejor la entrada al archivo. Usa negritas, itálicas, links a recursos externos o sintaxis de código. Lo que mejor te funcione para describirlo de la mejor manera.