Historial de página
Contenido:
Tabla de contenidos maxLevel 2 indent 20px
Resumen:
| Sugerencia |
|---|
|
Cumplimiento normativo
| Advertencia |
|---|
Las normas expuestas son de obligado cumplimiento. La STIC DGSIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STICDGSIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STICDGSIC. La STIC DGSIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC DGSIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras cabeceras de la tablas dónde se indican las fechas de entrada en vigor y versión.
| Expandir | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
1. Introducción
El objeto de esta normativa, es la definición de las pautas necesarias a seguir para la entrega de código fuente y la correcta ejecución de los procesos de integración continua. Basándose en las mejores prácticas actualmente aplicadas en la industria, se definen pautas de obligado cumplimiento con el objeto de garantizar la homogeneidad, trazabilidad y correcto funcionamiento de todos los procesos previos a la liberación del software en entornos previos y productos.
La normativa se ha organizado en páutas pautas que describen las reglas de verificación necesarias a cumplir en la entrega de código fuente.
Para más detalles sobre el modo de articular todas las pautas a continuación expuestas puede consultar la guía de ayuda a las entregas en la STIC.
1.1 Alcance
Esta normativa afecta a aquellos desarrollos corporativos que estén bajo el marco de gestión centralizada de la Subdirección Dirección General de Tecnologías Sistemas de la Información y las Comunicaciones del SAS.
2. Listado de pautas
| Ámbito: Commits | ||||||||
|---|---|---|---|---|---|---|---|---|
Pauta | Descripción | |||||||
P1 | No se permitirá por norma general hacer commits en master, develop o ramas support directamente, para ello se deberán de usar las demás ramas (release, feature,hu) dentro del flujo de Gitflow. | |||||||
P2 | Cada commit, incluido en una feature, debe incluir en su comentario el código Jira de la issue que corresponda, en caso de no disponer de dicha traza se referenciará el código de solicitud CGES que desencadena el cambio. | |||||||
P3 | Cada commit, incluido en una release, debe incluir la referencia a la issue de tipo | versionversión especificada en Jira a la cual afecta. | ||||||
C1 | Cada commit, incluido, debe ser atómico y pequeño, incluyendo solo cambios que están relacionados entre sí. | |||||||
C2 | Cada commit, incluirá un mensaje claro y descriptivo conteniendo una primera linea con un máximo de 70 caractéres dónde se da un resumen claro y conciso del cambio. Posteriomente se agregará una descripción resumida con caracter imperativo dónde se aclara "qué" a cambiado y "porqué" | |||||||
| Ámbito: Trazabilidad | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Pauta | Descripción | |||||||||||
P4 | Se Se ha de seguir el flujo adaptado de Gitflow para la STIC, dónde cada rama de mejora conlleva la entrega de una rama de tipo feature ( definida en git-flow) con nombre en el formato [feature/{Codigo_Jira_Mejora}_{Descripcion}]. Dónde:
| |||||||||||
P5 |
Se ha de seguir el flujo adaptado de Gitflow para la STIC, dónde donde cada rama de historia de usuario, conlleva la entrega de una rama de tipo feature ( definida en git-flow) con nombre en el formato [feature/{Codigo_Jira_Mejora}/{Codigo_Jira_HistoriaUsuario}_{Descripcion}]. Dónde:
| |||||||||||
P6 | Se ha de seguir el flujo adaptado de Gitflow para la STIC, dónde cada rama de Release cumplirá con la siguiente nomenclatura: [ Release/{Version} ]. Dónde:
| |||||||||||
P7 | Se ha de seguir el flujo adaptado de Gitflow para la STIC, dónde donde cada rama de Hotfix cumplirá con la siguiente nomenclatura: [ Hotfix/{Version} ]. Dónde:
| |||||||||||
P8 | Se ha de seguir el flujo adaptado de Gitflow para la STIC, dónde donde cada rama de soporte cumplirá con la siguiente nomenclatura: [ Support/{Version} ]. Dónde:
| |||||||||||
| Ámbito: Gestión de ramas en proyectos basados en metodologías ágiles | |||||||
|---|---|---|---|---|---|---|---|
Pauta | Descripción | ||||||
P9 | Se ha de seguir el flujo adaptado de Gitflow para la STIC cuando genere una rama para una mejora. El formato del nombre está definido en Flujos de trabajo en los repositorios STIC P4. | ||||||
P10 | Se ha de seguir el flujo adaptado de Gitflow para la STIC cuando genere una rama para una historia de usuario. El formato del nombre está definido en Flujos de trabajo en los repositorios STIC P5. | ||||||
P11 | Las ramas de historia de usuario se generan y cierran sobre las ramas de mejora en la que están contenidas, con la aceptación de los siguientes criterios al cierre:
| ||||||
P12 | Las ramas de Mejora permanecerán abiertas siempre, se cerrarán sobre la rama develop tras la aceptación de los siguientes criterios:
| ||||||
P13 | Las ramas de soporte, permanecerán siempre abiertas, en paralelo a la rama develop, y se comportará cómo como tal, permitiendo la apertura sobre ella de ramas de mejora, historia de usuario. | ||||||
P14 | Manejo de la rama support en escenarios que requieren versiones en paralelo (por ejemplo, evolución de la aplicación y evolución tecnológica ejecutadas en paralelo) a. La rama de soporte se crea desde la rama master. Concretamente desde el tag del que se desea mantener una versión en paralelo. b. La evolución del producto que vaya a mantenerse viva, estará contenida en las ramas develop y master. La de soporte se utilizará para aquel mantenimiento y/o evolución que tenga una fecha de finalización. c. La rama de soporte realizará funciones de "develop" y "master" para la evolución funcional de la aplicación. d. La rama support se crea siguiendo la nomenclatura support/version, teniendo versión como máximo 2 dígitos W.X. , donde W: Identifica el dígito mayor de la versión. X: Identifica el dígito medio de la versión. Será el jefe de proyecto quien decida el nombre de la rama y los dígitos de la misma. e. Los tags en la rama support continuarán siendo de 4 dígitos. Sonarqube trabaja con tags, por lo que el análisis de código no se verá afectado. f. Cuando se finalice la evolución tecnológica, si es necesario, habrá que "volcar" en develop, la rama soporte. Para hacerlo, se crearán previamente una rama de mejora en develop y una rama de mejora en support, haciendo el merge de dichas ramas y resolviendo los conflictos u adaptaciones que sean necesarios. g. Las ramas de soporte, nunca se cerrarán directamente sobre la rama develop. | ||||||
P15 | Las ramas de soporte, hotfix o release se regiran regirán por las nomenclaturas Flujos de trabajo en los repositorios STIC, Flujos de trabajo en los repositorios STIC nomenclaturas P8, P7 y P6 respectivamente. | ||||||
P16 | Está permitido entregar ramas internas sobre hotfix con la nomenclatura definida en el P5 para mejoras e historias de usuario, sólo en casos excepcionales cuando el desarrollo se considera urgente. Mas Más info | ||||||
| Ámbito: Gestión de ramas en proyectos basados en metodologías tradicionales (no ágil) | |||||||
|---|---|---|---|---|---|---|---|
Pauta | Descripción | ||||||
P17 | Vease P9. | ||||||
P18 | Vease P12. | ||||||
P19 | Vease P13. | ||||||
P20 | Vease P14. | ||||||
P21 | Vease P15. | ||||||
| Ámbito: Gestión de tags | |||||||
|---|---|---|---|---|---|---|---|
Pauta | Descripción | ||||||
P22 | Nunca se nombrarán tags con el sufijo "-Snapshot" o variantes en las ramas master, support. | ||||||
P23 | El formato permitido para un tag siempre será del tipo W.X.Y.Z, dónde: w. Identifica el digito dígito mayor de la versión. X. Identifica el dígito medio de la versión. Y. Identifica el digito dígito menor de la versión. Z. Identifica el dígito de entrega de la versión. | ||||||
P24 | Excepcionalmente y bajo acuerdo previo entre el área de gobernanza y el proyecto se permitirán versiones de sprint identificadas con el sufijo SP"n", dónde n identifica el número secuencial del sprint al que representa. | ||||||
P25 | Excepcionalmente y bajo acuerdo previo entre el área de gobernanza y el proyecto se permitirán versiones candidatas a release, identificadas por el sufijo RC"n", dónde "n" identifica un secuencial exclusivo para las candidatas a release. | ||||||
P26 | Las ramas de soporte, tagearán sobre la misma rama de soporte la versión prevista, sin hacer uso de ramas release. | ||||||
P27 | En proyectos que empaquetan haciendo uso de Maven, al tagear sobre el repositorio de código fuente la versión identificada en los artefactos generados ha de ser coincidente con la versión tageada, siguiendo el formato de versión indicado en Flujos de trabajo en los repositorios STIC P23. | ||||||
P28 | En proyectos que empaquetan haciendo uso de node.js, al tagear sobre el repositorio de código fuente, la versión identificada en los artefactos generados ha de ser coincidente con la versión tageada, siguiendo un formato de 3 dígitos similar al de Flujos de trabajo en los repositorios STIC P23 y prescindiendo del dígito Z. | ||||||
| Ámbito: Gestión de la entrega de código | |||||||
|---|---|---|---|---|---|---|---|
Pauta | Descripción | ||||||
P29 | Las entregas al repositorio de la STIC sólo soportarán cómo como ramas abiertas aquellas que sean del tipo, soporte, develop o master. | ||||||
P30 | Las ramas de tipo hotfix o release, así como cualquier otra rama que haya sido de uso interno en su repositorio empresarial, deben haberse cerrado correctamente sobre las ramas de soporte o develop, previamente a su entrega al repositorio de la STIC. | ||||||
P31 | Al entregar, la rama MASTER estará como máximo al mismo nivel que la rama DEVELOP, nunca la rama MASTER podrá estar por encima de la rama DEVELOP. En todo caso la rama DEVELOP sí que podrá estar por encima de la rama MASTER, dado su carácter de rama de trabajo. | ||||||
P32 | Cuando se realice una entrega de una nueva versión, deberá existir el TAG (desde la rama MASTER) correspondiente a dicha versión. | ||||||
P33 | Nunca se entregarán tags al repositorio de la stic que no cumplan escrupulosamente con las reglas definidas en Flujos de trabajo en los repositorios STIC P22. | ||||||
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2