Este documento presenta una guía sobre el uso de Gitlab como repositorio de control de versiones para proyectos de software del gobierno de la Ciudad Autónoma de Buenos Aires. Explica el objetivo, audiencia, procedimiento, estructura de proyectos, controles de calidad, configuración y consideraciones al usar Gitlab para versionado de código.
0 calificaciones0% encontró este documento útil (0 votos)
82 vistas7 páginas
Este documento presenta una guía sobre el uso de Gitlab como repositorio de control de versiones para proyectos de software del gobierno de la Ciudad Autónoma de Buenos Aires. Explica el objetivo, audiencia, procedimiento, estructura de proyectos, controles de calidad, configuración y consideraciones al usar Gitlab para versionado de código.
Este documento presenta una guía sobre el uso de Gitlab como repositorio de control de versiones para proyectos de software del gobierno de la Ciudad Autónoma de Buenos Aires. Explica el objetivo, audiencia, procedimiento, estructura de proyectos, controles de calidad, configuración y consideraciones al usar Gitlab para versionado de código.
Este documento presenta una guía sobre el uso de Gitlab como repositorio de control de versiones para proyectos de software del gobierno de la Ciudad Autónoma de Buenos Aires. Explica el objetivo, audiencia, procedimiento, estructura de proyectos, controles de calidad, configuración y consideraciones al usar Gitlab para versionado de código.
Descargue como PDF, TXT o lea en línea desde Scribd
Descargar como pdf o txt
Está en la página 1/ 7
Guía de Gitlab
Agencia de Sistemas de Información
Gobierno de la Ciudad Autónoma de Buenos Aires
Guía de Gitlab Pág. 1 / 7
Índice REPOSITORIO DE CONTROL DE VERSIONES ............................................................................. 3 OBJETIVO ........................................................................................................................................... 3 AUDIENCIA ........................................................................................................................................ 3 PROCEDIMIENTO .............................................................................................................................. 3 ESTRUCTURA DE UN PROYECTO .................................................................................................. 3 CONTROLES DE CALIDAD .............................................................................................................. 4 CONFIGURACION ............................................................................................................................. 5 VERSIONADO DE CODIGO - GITLAB ............................................................................................. 5 CONSIDERACIONES A TENER EN CUENTA ............................................................................................... 7
Guía de Gitlab Pág. 2 / 7
REPOSITORIO DE CONTROL DE VERSIONES
OBJETIVO
El objetivo del presente documento es unificar las entregas de paquetes de software en una única herramienta de control de versiones o SCM (del inglés Software Control Management), a través de un proceso y estructura definidos que permitan a las diferentes áreas de la ASI realizar las actividades e intercambios con los proveedores. Es de carácter obligatorio realizar este proceso para llevar a cabo las actividades de control de cambios tanto para aplicaciones nuevas como entregas de nuevas versiones de aplicaciones existentes.
AUDIENCIA
La audiencia del presente documento involucra a todas las áreas técnicas de las reparticiones y proveedores de software del GCABA que realizan entregas de software a la ASI.
PROCEDIMIENTO
El sistema de control de versiones seleccionado por la ASI es GIT, el cual pertenece al tipo de arquitectura de repositorios de información distribuidos.
El repositorio para un proyecto dentro de GIT y sus usuarios son creados en la etapa denominada Setup del Proyecto en la cual el referente técnico de un proyecto declara a la ASI el inicio de un proyecto de Software.
Todo el código fuente necesario para un proyecto así como también para el esquema, sus migraciones, scripts y todo el material entregable para el proyecto, deberá estar presente en el repositorio GIT. Se exceptúa la documentación del proyecto como los documentos funcionales, arquitectura que debe residir en el Confluence de ASI.
ESTRUCTURA DE UN PROYECTO
La ASI generará el repositorio del proyecto y otorgará los acceso en GIT al momento del iniciar el proyecto.
En la carpeta source/ debe estar contenido todo el código fuente de la aplicación y el archivo de configuración de dependencias, el cuál debe listar las mismas especificando el número de versión exacta para cada una de ellas. No se aceptarán paquetes compilados como parte de la entrega.
En el directorio raíz del repositorio deberá encontrarse un archivo README.md el cual debe contener la información necesaria para realizar la primera implementación del aplicativo.
Luego, para cada nueva versión que se entrega es obligatorio sumar al archivo UPGRADE.md, con las instrucciones para llevar a cabo la instalación, indicando la fecha en la que se produjo dicha actualización y los cambios que se realizaron en el archivo CHANGELOG.md a nivel funcional, incluyendo en el mismo lo siguiente:
• Nro. de tickets de bugs/requerimientos/incidentes resueltos (nro. asociado en la Herramienta
de seguimiento y control de cambios definidas en el proyecto)
Guía de Gitlab Pág. 3 / 7
• Funcionalidades incluidas (si corresponde),
• Sprint correspondiente (versión preliminar).
Es obligatorio contar en la carpeta scripts para el caso de utilizar despliegues en máquinas virtuales. Debe contar con los comandos necesarios para efectuar un rollback en caso de que el deploy falle. Dichoscript deberá efectuar tanto rollback de código como de base de datos y configuración. Es responsabilidad del desarrollador mantener la lógica necesaria para evitar que se pierda información valiosa en este proceso. Todos los script deben contar con una forma adicional que verifique y valide que la ejecución es exitosa o no, a modo de validación, como por ejemplo que contenga las instrucciones que logueen en un log que pueda ser rescatado y enviado a los interlocutores.
Adicionalmente, debe ser utilizado el comando de mayor nivel de información (verbouse). En caso de existir integraciones/acoplamiento con servicios externos al paquete a instalar, se debe verificar que la instalación relacionada se comunica correcta o incorrectamente y es obligatorio detallar la forma de integración en el documento de arquitectura.
Si se considera que el despliegue a realizar puede poner en riesgo la información almacenada en la base de datos del proyecto, se deberá realizar un backup de los datos en el README.md y en la solicitud del pedido del pasaje de ambiente.
Los proyectos deberán contar como mínimo con una rama DEV y una MASTER. En DEV se realizarán las entregas parciales y verificaciones implementadas en la herramienta con el fin de contar en forma proactiva un auto examen de calidad. Dicha rama es de uso exclusivo del equipo que construye. Una vez que se cuenta con la versión candidata, en condiciones de avanzar a otro ambiente, se actualiza a la rama MASTER con el TAG correspondiente.
A partir de esta acción se considera la entrega formal y se inicia el proceso de despliegue y seguimiento.
En la rama MASTER se ejecutarán los mismos controles que en DEV y se avanzará con el despliegue si los mismos son satisfactorios.
En el archivo .gitignore dentro del repositorio deberán incluirse los archivos de configuración y todos aquellos archivos que no formen parte del proyecto y que por alguna razón existan en el directorio del mismo (Ej.: archivos de sistema, configuración, archivos subidos por usuarios, etc.)
CONTROLES DE CALIDAD
Cada proyecto de Git cuenta con la asociación de los controles Code Quality, SAST, DAST y Dependency Scanning. Dichas revisiones se activan a partir de los commits y tags que se van generando y dependiendo de la tecnología utilizada.
Code Quality proporciona una revisión automatizada del código, está basada en la herramienta gratuita Code Climate Engines.
El usuario cuenta con los informes de resultados correspondientes accediendo al Dashboard de la
aplicación en Git.
CONFIGURACION
A continuación, se detalla una guía de los pasos necesarios para vincular un puesto al GIT GCBA:
1. Acceder a la URL que al momento del setup el GCABA entregará. Dicho acceso se encontrará habilitado temporalmente durante el proyecto. En caso de inactividad del usuario en la herramienta (60 días), se procederá a la desactivación por cuestiones seguridad y ante una nueva necesidad, deberá solicitar la reactivación con la Mesa de ayuda de la Agencia.
2. Para vincular el puesto con el proyecto en GIT, se cuentan con dos opciones:
Generar una Key SSH y vincularla en el profile de GIT.
Utilizar un cliente GIT tipo UI y autenticarse con el usuario y contraseña de GIT.
3. Clonar el repositorio para obtener la estructura de carpetas Estándar.
4. Realizar el commit de los archivos generados respetando la estructura de carpetas.
VERSIONADO DE CODIGO - GITLAB
En la etapa de desarrollo continuo se debe utiliza la rama DEV, y versionar cada commit indicando el ISSUE asociado o un comentario asociado al cambio.
Guía de Gitlab Pág. 5 / 7
Ej:
git commit –m “1.0.1 APP-DEMO-04”
git commit –m “1.0.2 Fix funcionalidad …”
Donde “APP-DEMO-04” refleja el ISSUE asociado a la herramienta de Gestión del Cambio.
Al momento de realizar una entrega en la rama Master se deberá identificar el commit como un Release Candidate de la siguiente forma:
git commit -m <identificación del release candidate>” refleja la intención del Proveedor de entregar un nuevo release -incorporando N cambios sobre la versión anterior- y por lo tanto el mensaje que describe el commit representa dicha intención. Ejemplo para una aplicación que tiene la versión 3.3 en Producción se incorporan 3 nuevas funciones y 2 cambios (todos detallados en el documento CHANGELOG.MD). Se realiza el comando:
git commit –m “3.4.RC-1”
Además, de incrementar el número de versión (en este caso el segundo dígito por tratarse de una modificación menor) se le agrega la identificación “RC” para señalar que se trata de un candidato a ser implementado (release candidate) y con el número #1 porque es la primera entrega luego de una implementación exitosa.
Si durante el proceso de deploy se detecta algún problema que impide llegar a la implementación exitosa y que requiere subir nuevos cambios al código, simplemente se repite la operación pero esta vez el comando será:
git commit –m “3.4.RC-2”
De esta forma queda documentado un segundo candidato, y así sucesivamente hasta que se obtenga una versión exitosa.
En ese momento, el equipo de despliegues procederá a generar una etiqueta (git tag) con el número de versión reemplazando el “RC-x” por un “.0”, por lo que la versión implementada exitosamente estará identificada así:
git commit “3.4.0”
Guía de Gitlab Pág. 6 / 7
Versionado de FIX
Supongamos que mientras el equipo de desarrollo sigue avanzando en el proyecto y entrega la siguiente versión (en nuestro ejemplo, 3.5.RC-1), se produce un problema que requiere la inmediata corrección del código productivo (3.4.0). En ese caso, se crea una nueva rama (git branch) identificada en la rama FIX con la última versión productiva (3.4.0) y se corrige el problema, subiendo al repositorio el arreglo como:
git commit –m “3.4.FIX-1”
Una vez que el fix ha sido autorizado e implementado, el equipo de la Agencia genera la etiqueta:
git tag “3.4.1”
El tercer dígito indica que la versión productiva tiene uno o más arreglos, independientemente de los release candidates que se estén implementando. Estos arreglos podrían ser agregados o no al código en desarrollo, como en el caso de workarounds para problemas que se solucionan justamente con una próxima versión.
Consideraciones a tener en cuenta
El equipo de desarrollo solamente indica las versiones candidatas a despliegue (RC) o arreglos (FIX) en el comentario del “git commit”, seguido de un número secuencial correlativo.
El equipo de Despliegue es quien genera las etiquetas de TAGS para las versiones productivas y arreglos de emergencia.
La lista de los cambios realizados con respecto a la versión anterior deben estar documentados (ej. CHANGELOG.MD) y pasos a seguir para la implementación del Release Candidate entregado en el archivo UPGRADE.md (ej, ejecución de script .sh, pasos para ejecutar archivo Ansible).
