INSTRUCTIVO PARA USO DEL GIT
Contents
1. aplicaci n debe contar con su carpeta correspondiente y la estructura definida NOMBRE PROYECTO e build e database o database sql o migrations o version name orden sql O source documents Instructivos Documentos ASI scripts opcional ej Scripts para rollback Scripts TestServices sh tests patches gitignore gitmodules opcional Makefile opcional README md CHANGELOG md requirements txt En la Carpeta Build se deben incluir todos los binarios compilados en caso de tratarse de un P gina 2 de 4 ANEXO Control de Versiones GIT lenguaje compilado En la carpeta Documents incluir en cada entrega la documentaci n relacionada a la versi n o el proyecto que se encuentra definida como obligatoria en el Est ndar de Desarrollo Ej documento de arquitectura casos de prueba manuales etc Para realizar la primera instalaci n es imprescindible contar con el Manual de Instalaci n completo y el Documento de Arquitectura Solicitar los template a la ASI como referencia 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 En caso de necesitar aplicar algun tipo de parche al framework utilizado los mismos deberan alojarse dentro de la carpeta patches de la ra z del repositorio En el directorio ra z del repositorio deber encon2. ANEXO Control de Versiones GIT INSTRUCTIVO PARA USO DEL GIT Anexo Gobierno de la Ciudad Aut noma de Buenos Aires ANEXO Control de Versiones GIT OBJETIVO El objetivo del presente documento es poder unificar las entregas en una sola herramienta de control de versiones o SVC del ingl s System Version Control 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 deaplicaciones existentes Como aclaraci n informarmos que stas entregas no reemplazan la entrega formal por Mesa de Entradas en contrataciones licitadas sino que es un medio adicional obligatorio para facilitar las tareas operativas ALCANCE El alcance del presente documento involucra a todos los Organismos que interect an con la ASI as comolos proveedores del GCABA PROCEDIMIENTO El sistema de control de versiones seleccionado por la ASI a utilizar es GIT el cu l pertenece al tipode arquitectura de repositorios de informaci n distribuidos Todo el c digo fuente necesario para el proyecto as como tambi n para el esquema sus migraciones y todo el material generado para el proyecto deber estar presente en un repositorio creado a tales efectos Estructura de proyecto Cada
3. etiqueta release en el commit donde los mismos estuvieran corregidos Hecho esto se deber enviar la versi n generada nuevamente con su correspondiente pedido Es obligatorio contar en la carpeta scripts con los comandos necesarios para efectuar un rollback en caso de que el deploy puediera fallar Este script 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 verifica y valida 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 Adicionalemente 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 debe contarse con una forma de verificar que la instalaci n relacionada se comunica correcta o P gina 3 de 4 ANEXO Control de Versiones GIT incorrectamente y es obligatorio detallar la forma de integraci n en el documento de arquitectura Los ambientes donde se implementan las entregas no contemplan accesos a servicios externos por lo tanto cualquier excepci n debe estar documentada justificada y la ASI puede aprobar o no el acceso Para no generar reworking solicitamos anticipar este tip
4. no con los permisos necesarios as como la creaci n de la estructura de carpeta correspondiente CONFIGURACION A continuaci n una gu a de los pasos necesarios para vincular un puesto al GIT GCBA Acceder a la URL http git asi buenosaires gob ar help ssh para generar la Key de ssh Una vez que se cuenta con la Key agregarla en el profile del usuario del GIT http git asi buenosaires gob ar profile keys Ejecutar los comandos para clonar el proyecto que la ASI cre para tal fin e inform Subir los archivos respetando el contenido en las carpetas definidas P gina 4 de 4
5. o de necesidad al comienzo del proyecto Si se considera que el deploy a realizar puede poner en riesgo la informaci n almacenada en la base de datos del proyecto se deber indicar al rea de infraestructura la realizaci n de un backup de los datos previo a la realizaci n del mismo en el README md y en la solicitud del pedido del pasaje de ambiente Debe existir una rama estable master que es la que siempre contiene las versiones entregadas a la ASI y se recomienda generar una rama de desarrollo dev para desarrollo 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 En la carpeta Tests incluir los casos de pruebas funcionales y no funcionales y los informes con la evidencia de los resultados El archivo de dependencias deber estar inclu do dentro de la carpeta source con todas las dependencias externas necesarias para el correcto funcionamiento de la aplicaci n A continuaci n se eumeran los ejemplos para las plataformas reguladas por la ASI requierements txt para python package json para nodejs pom xml para java composer js para php Alta de Usuario En caso de no tener un usuario de la herramienta el Referente t cnico de la ASI realizar las gestiones necesarias para brindarle u
6. trarse un archivo README md el cual debe contener la informaci n necesaria para realizar la implementaci n del aplicativo Luego para cada nueva versi n que se entrega es obligatorio sumar al archivo README md 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 incluyendo en el mismo lo siguiente Nro de tickets de bugs resueltos nro asociado en la Herramienta de seguimiento y control de cambios definidas en el proyecto Funcionalidades inclu das si corresponde Sprint correspondiente versi n preliminar Cada versi n deber estar etiquetada con correspondiente nombre con el formato vx x x Cuando el Referente del proyecto de la ASI tiene la aprobaci n del Usuario y QA si interviene en le proceso de la versi n pasar de ambiente el responsable de la entrega deber etiquetar en el GIT con el formato r vx x x Al momento de realizar el pedido de instalaci n por la v a formal establecida por la ASI actualmente es la herramienta Mantis debe informarse la ltima etiqueta con formato de RELEASE Si una versi n aprobada llegara a producci n y la misma contuviese errores el Referente de proyecto en conjunto con el Equipo de Desarrollo Interno o Proveedor deber n corregir dichos errores quitar la etiqueta de release de ese commit agregar al mismo la etiqueta de rf vx x X y crear un nueva
Download Pdf Manuals
Related Search