Estandarización de aplicaciones y librerías

Transcripción

1 Objeto Describir como se realiza el mantenimiento y la estandarización aplicaciones y librerías para compartir entre los sarrolladores LabHuman. Amás se scribe cómo se realiza el proceso almacenamiento l código todos los sarrollos llevados a cabo en LabHuman. Afecta/Alcanza Afecta a todos los programadores, salvo molado. Alcanza a toda el Área proyectos. Realización 3.1. Generalidas Para agilizar y simplificar la metodología trabajo, los sarrolladores tienen que utilizar un sistema control código centralizado en una unidad red. Los gestores control código proporcionan una serie ventajas: Permiten seguir la historia los archivos y directorios, incrementando la seguridad y mejorando el control versiones. Las modificaciones (incluyendo cambios a varios archivos) son atómicas. Manejan eficientemente archivos binarios. Permiten la edición por más una persona a la vez así como el bloqueo selectivo archivos. El gestor control código varía en función l perfil l sarrollo afectado. Así se distinguen los siguientes perfiles: Desarrollo librerías Desarrollo plugins Desarrollo web Desarrollo en el motor gráfico Unity3d Otros sarrollos Concretamente, se utilizan dos tipos gestores control código, Subversion y ASSET SERVER. Subversion está pensado para almacenar código en cualquier lenguaje programación, por lo que se utiliza en todos los tipos sarrollo salvo los realizados con Unity3d. Para este último se utiliza ASSET SERVER, que es el gestor control código propio Unity3d, el cual incorpora funciones específicas para versionar eficientemente tipos objetos propios l motor. Todo código ntro l repositorio código, be seguir la premisa porse compilar al ser scargado, inpendientemente las referencias externas que tenga. Esto implica que pue existir duplicidad cierto tipo código, pero se evita el problema las referencias y la pérdida tiempo que supondría actualizarlas. Página 1 7

2 3.2. Uso y acceso a Subversión Para accer, solamente es necesario la crencial dominio cada usuario, y en función ellas, subversión automáticamente se conectará al repositorio. La dirección l repositorio es: De esta dirección colgaran los diversos proyectos y las subcarpetas. Por ejemplo l proyecto mayordomo2 el código la web estaría en esta dirección: Hay muchas formas usarlo, la más sencilla es usar TortoiseSVN que se integra en Windows, o usar algún plugin. Ejemplo: 1 Crear un directorio l proyecto 2 Botón la recha Svn checkout y poner el repositorio 3 Meter el código ntro 4 Seleccionar lo que se quiera y darle a add 5 Hacer un commit. ( y se sube al repositorio) Será necesario, hacer un update al principio l día; y un commit antes abandonar el puesto trabajo para que quen registradas todas las modificaciones que se hayan hecho durante la jornada Elementos a almacenar En Subversion se creará una carpeta por cada proyecto, a la que se asignarán los permisos acceso l personal que vaya a trabajar en cada proyecto, según lo que se indique en la ficha arranque l proyecto o el Gepla o Coci responsable l proyecto, le comunique al responsable sistemas. Amás, existen otras carpetas que se utilizarán para almacenar código uso común en LabHuman, que posteriormente a su sarrollo, se reutilizarán y personalizaran para cada uno los proyectos. Según la tipología l código generado, berá programarse ntro : librerias_externas: aquí se guardarán las librerías externas que se usan para sarrollo habitual. Especialmente importante es el caso aquellas librerías que constituyan penncias otras sarrollo interno. librerias_internas: librerías sarrolladas en el grupo. Plugins_GStudio: plugins para el motor Game Studio Plugins_Unity: Plugins para el motor Unity. Plugins_IPF: plugins para el motor IPF. aplicaciones: pequeñas aplicaciones o utilidas exclusivamente sarrollo interno. Es cir para el caso una librería que posteriormente se utilizará en varios proyectos que en LabHuman se sarrollarán, se programará en librería interna (o externa si fuera el caso), y posteriormente a su sarrollo, ntro la carpeta los proyectos que contengan esta librería se scargará nuevo esta librería y se personalizará para el proyecto que en que se esté trabajando. Los permisos a estas carpetas berán solicitarse por el Gepla o Coci responsable a Sistemas para que actualice los mismos y pueda llevarse un control los permisos asignados a cada carpeta. Página 2 7

3 Reglas y recomendaciones readme.xml El fichero readme.xml aporta información relevante sobre el proyecto almacenado, así como su funcionamiento, modo que aunque con el sistema actual ya no es necesario, se recomienda su uso. La información que ha guardar sigue la siguiente estructura: readme.xml que aparece colgada en la intranet en el apartado sarrollo y presenta los contenidos siguientes: Name: NOMBRE_DE_LA_LIBRERIA, se indica el nombre la librería Author_list: autor o autores, si hay más uno. Pue que no se únicamente el que escribió el código, sino que pue haber autor material e intelectual. Description: Descripción breve, en la que se explique el funcionamiento y talles relevantes l proyecto Remark: permite almacenar otro tipo información o aspectos a consirar no contemplados en los puntos anteirores.. Versión: be coincidir con el nombre especificado en la carpeta correspondiente, y contendrá la información abajo scrita. Amás, habrá un apartado por cada versión existente. o Number: Número versión en la que se encuentra o Date: Fecha creación la versión. o system_list: Se ben incluir los sistemas sobre los que se ha testeado la librería o aplicación y funciona correctamente. o penncy_list: Se indican las penncias existentes. Es necesario que estas penncias se especifiquen lo máximo posible, siendo indispensable indicar librerías y versiones las que pen; así como la dll concreta la que pen,si fuera el caso o changelog: Se indican los cambios realizados respecto a la versión anterior. o Remark: permite almacenar otro tipo información o aspectos a consirar no contemplados en los puntos anteirores Sistema versiones En cuanto a versiones se refiere, la nomenclatura expresa si una versión es estable o si por el contrario aún está en proceso sarrollo. Las versiones estables tienen la siguiente forma: vversion_mayor.version_menor Ejemplos válidos serían v1.0 o v2.4. Las versiones estables se han mantener en el repositorio, ya que pue haber penncias hacia ellas en cualquier momento. Amás, únicamente se mantendrá una sola versión en sarrollo, que amás será, lógicamente, la última. Este número se incrementará a criterio l sarrollador la siguiente forma: V0.1;v0.2; v1.0; v5.0;v6.1 sin que necesariamente sea consecutivo pero si superior al perteneciente a la antigua versión estable,en cualquier caso. No se corregirán bugs ni se añadirá funcionalidad en versiones estables, sino que estos cambios sólo afectarán en la versión en sarrollo. En cualquier caso, las actualizaciones que se lleven a cabo en las versiones, bien sea introduciendo una versión estable o subiendo una modificación sobre la versión en sarrollo, han ser bidamente plasmadas en el readme.txt, modo que esté siempre actualizado. Página 3 7

4 Otros Amás hay que tener en cuenta las siguientes consiraciones: Si se sarrolla una librería, documentar al menos las partes que sean interés para los clientes la misma. Amás, es aconsejable aportar un ejemplo uso la misma. El nombre las librerías generadas (estáticas o dinámicas), para las versiones bug se añadirá d al nombre la librería generada. Ejemplo: MiLibreria.lib (release) y MiLibreriad.lib (bug). En la medida lo posible, únicamente se copiarán las dll o elementos estrictamente necesarios para que se ejecute la versión ejemplo (no se copia un proyecto, sino lo que sea necesario). Amás, en cualquier caso, especificar dichas penncias en el readme.txt. Evitar espacios en los nombres directorios y ficheros, y en su lugar emplear _. Evitar también el uso otros caracteres salvo los siguientes: letras (sin acentos, diéresis ), números, guión normal ( - ), guión bajo ( _ ) y punto (. ). Este último 3.3. Uso y acceso al Asset Server Existe un administrador encargado dar alta los proyectos y los usuarios. Amás, realiza la asignación l personal a los proyectos, forma que los usuarios solo tendrán acceso a los proyectos que éste les asigne. Los usuarios se validarán con el usuario y contraseña que el administrador les proporcione. La dirección l servidor es: srverp.i3bh.com. La forma utilizarlo es: 1- Crear un proyecto nuevo en Unity3D con el nombre que se see. 2- Ir al menú Edit/Project settings/editor y seleccionar Asset Server l splegable Version Control. 3- Des el menú Window Unity3D accer a la opción Version Control Página 4 7

5 4- En la ventana que se abre, introducir los datos l servidor y l usuario. 5- Presionar botón Show Projects 6- De la lista proyectos que aparecen, seleccionar al que se sea conectar el proyecto actual. 7- Seleccionar la versión seada la lista versiones y presionar Update para scargarla. Será necesario, hacer un update al principio l día; y un commit antes abandonar el puesto trabajo para que quen registradas todas las modificaciones que se hayan hecho durante la jornada. Registros REGISTRO RESP. CREACION RESP. CONSERVACION TIEMPO DE CONSERVACIÓN. Código en subversion Desarrollador Gestor Sistemas Infinido Carpeta l proyecto Área Sistemas Área Sistemas Infinido Página 5 7

6 Resumen Se ha centralizado en una unidad red tanto librerías externas como código interno. Para ello se han finido unas estructuras carpetas ntro l gestor código para almacenar esta información según el tipo elemento a almacenar, con lo que se consigue que resulte más fácil compartir y reutilizar dichos recursos. Amás es un método trabajo mucho más seguro. Documentación referencia Capítulo 7 l Manual. Mapa procesos DESARROLLO, MANTENIMIENTO Y USO DE LIBRERÏAS LOCAL Traspaso automático código: Librerías, Plugins y aplicaciones Subversion Versión finitiva CARPETA DESARROLLODE L PROYECTO EN N Observaciones Página 6 7

7 Histórico cambios REVISION FECHA DESCRIPCIÓN 1 24-julio-09 Creación l documento Julio Dic Dic Jun-15 REALIZADO POR Moisés Ferrer Serra Se elimina el punto inventario los Vicente directorios almacenados Abarca Se modifica el documento para comentar que se utiliza subversión. Se modifica punto 3.1 comentando el nuevo sistema subversion, se hacen variaciones en el 3.2 ya que ahora no se Área almacena el código en S, si no en subversion. Se Sistemas elimina el punto 3.3, y 3.4, ya que no son necesarios establecer estructura para proyectos ni para directorios, ni almacenamiento código. Se modifica el documento para explicar la utilización subversión en Unity Se modifica el documento para adaptarlo a la forma actual trabajar los sarrolladores. Área Sistemas APROBADO POR Comité Comité Comité Comité David Pérez y Comité José Roda Página 7 7