Implementación del proyecto ArduPlane en el servidor de integración continua del GARP

Texto completo

(1)i. Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales. TRABAJO DE DIPLOMA Implementación del proyecto “ArduPlane” en el servidor de integración continua del GARP. Autor: Andrés Pérez Ruíz. Tutor: Ing. Rubén Eduardo Carlés Barrero. Santa Clara 2015 "Año 57 de la Revolución".

(2) ii. Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales. DAS C. Digitally signed by DASC DN: cn=DASC, c=<n, o=UCLV, ou=FIE Date: 2015.06.19 11:28:32 -04'00'. TRABAJO DE DIPLOMA Implementación del proyecto “ArduPlane” en el servidor de integración continua del GARP. Autor: Andrés Pérez Ruíz e-mail: [email protected]. Tutor: Ing. Rubén Eduardo Carlés Barrero e-mail: [email protected]. Santa Clara 2015 "Año 57 de la Revolución".

(3) iii. PENSAMIENTO Terminas un ciclo, cierras un capítulo, te despides de personas y lugares que tal vez ya no frecuentarás, pero que han formado parte de tu vida por algún tiempo. Crecer duele. Pero al mismo tiempo no puedes evitar entusiasmarte por la nueva etapa que próximamente empiezas. Nuevos sueños, nuevas metas y retos, nuevas personas y nuevos lugares. Habrá compañeros que en efecto, no volverás a ver, pero muchos de ellos podrán seguir siendo parte de tu vida, y algunos de ellos, te acompañaran por siempre. No importa dónde estén, no importa cuánto tiempo pase, se buscarán, se encontrarán, y formarán parte uno de otro de su misma esencia. El ciclo de la vida continúa, y muchas veces cada final es un nuevo comienzo, una libreta en blanco, una nueva oportunidad, ser como siempre has querido ser, hacer lo que siempre has querido hacer, cambiar lo que siempre has querido cambiar. “Cada persona diseña su propia vida, la libertad le da el poder de llevar a cabo su destino” Mayra Gris de Luna..

(4) iv. DEDICATORIA. A mis padres María de los Ángeles y Leonel, Por darme la vida y ser un ejemplo a seguir. A toda mi familia y personas que me apoyaron en todo este transcurso de tiempo, Ya que fueron un pilar fundamental para que obtuviera este logro..

(5) v. AGRADECIMIENTOS. A mis padres por estar siempre a mi lado cuando más lo necesito, en los buenos y malos momentos; por mostrarme en cada momento su apoyo incondicional y el interés para que estudie y me desarrolle completamente en todos los aspectos de mi vida, ya que son para mí la base fundamental; pues ellos me han sabido guiar, levantarme y sostenerme sin el camino importar y poniéndome antes sus compromisos personales; gracias por mostrarme que todo lo que me proponga lo puedo lograr y que con un poco de esfuerzo nada es imposible sin importar el tiempo y el espacio. A mis hermanos Julio, Miguel y Tania por ser parte de mi vida, por ayudarme a crecer y madurar junto con ellos. A mis tías y tíos, mis abuelas y todas las personas que han estado presentes en mi formación de una forma u otra dándome su apoyo incondicional. Todos ellos han formado una parte importante dentro de mí, pues siempre me han acompañado sin importar el contexto y a la vez me han intentado apoyar brindándome su comprensión, y me han dado el ejemplo de que todo es posible sin importar las condiciones. A todos mis amigos de la UCLV con los que compartí buenos momentos y me dejaron los mejores recuerdos. A mi novia por ser la persona tan maravillosa que es y por brindarme todo su apoyo incondicional. Y a todas las personas que pensaron que nunca iba a poder lograrlo..

(6) vi. RESUMEN. El aprovechamiento a nivel comercial y el número de investigaciones basadas en vehículos autónomos aéreos ha venido en crecimiento en los últimos años a nivel mundial. El desarrollo del software viene adoptando una tendencia a la liberación del código fuente y el conocimiento que lo soporta. El Grupo de Automatización, Robótica y Percepción (GARP) de la Universidad Central “Marta Abreu” de Las Villas (UCLV) ha adquirido varios años de experiencia en el software del Unmanned Aerial Vehicle (UAV) siendo de su interés desarrollar este de forma local. Este trabajo consiste en crear una infraestructura adecuada para desarrollar este software de forma local, con la calidad y aplicando la política de desarrollo del grupo GARP. La tarea principal es que el software cuente con la infraestructura adecuada para su acrecentamiento. También se analizan los datos recopilados en experimentos hechos a la infraestructura y se describen los resultados obtenidos en las pruebas efectuadas..

(7) vii TABLA DE CONTENIDOS. DEDICATORIA ....................................................................................................................iv AGRADECIMIENTOS .......................................................................................................... v RESUMEN ............................................................................................................................vi INTRODUCCIÓN .................................................................................................................. 1 CAPÍTULO 1. 1.1. REVISIÓN BIBLIOGRÁFICA................................................................. 6. Software de control de versiones ............................................................................. 6. 1.1.1. Flujo de trabajo ................................................................................................. 9. 1.1.2. Ramificación (branching) ............................................................................... 10. 1.1.3. Alternativas de software de control de versiones ........................................... 11. 1.1.4. Comparativa .................................................................................................... 14. 1.2. Sistemas de Integración Continua .......................................................................... 15. 1.2.1. Método de trabajo ........................................................................................... 17. 1.2.2. Ventajas .......................................................................................................... 18. 1.2.3. Desventajas ..................................................................................................... 18. 1.2.4. Alternativas de software de Integración Continua .......................................... 19. 1.2.5. Comparativa .................................................................................................... 21. 1.3. Infraestructura del grupo GARP ............................................................................ 23. 1.4. Consideraciones parciales del capítulo .................................................................. 26. CAPÍTULO 2.. IMPLEMENTACIÓN. DEL. SOFTWARE. ARDUPLANE. Y. CONFIGURACIÓN DE LOS SERVIDORES. .................................................................... 27 2.1. Entorno de trabajo .................................................................................................. 27. 2.2. Prerrequisitos necesarios ........................................................................................ 28.

(8) viii 2.3. Servidores de control de versiones Git................................................................... 29. 2.3.1 Creación del repositorio en Git ............................................................................ 33 2.3.2 Ramificaciones en Git ........................................................................................ 35 2.4. Servidor de Integración Continua Jenkins ............................................................. 37. 2.4.1. Integración con Git ......................................................................................... 37. 2.4.2. Configuración básica ...................................................................................... 38. 2.4.3. Nuevas tareas .................................................................................................. 39. 2.5. Consideraciones parciales. ..................................................................................... 42. CAPÍTULO 3.. EMPLEO DE ENTORNOS DE PROGRAMACIÓN Y DETECCIÓN. TEMPRANA DE ERRORES. .............................................................................................. 43 3.1. Resultados obtenidos en el servidor de integración continua ................................ 43. 3.2. Utilización de plataformas de desarrollo IDEs ...................................................... 46. 3.2.1. Vínculo de Eclipse con Gerrit. ........................................................................ 47. 3.3. Análisis económico ................................................................................................ 53. 3.4. Consideraciones parciales. ..................................................................................... 55. CONCLUSIONES Y RECOMENDACIONES ................................................................... 56 Conclusiones ..................................................................................................................... 56 Recomendaciones ............................................................................................................. 57 REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 58 ANEXOS .............................................................................................................................. 60 Anexo I. Interfaz principal de Jenkins ........................................................................... 60. Anexo II. Interfaz de eclipse vinculado a repositorio con el software ArduPlane. cargado.. 61.

(9) INTRODUCCIÓN. 1. INTRODUCCIÓN. El proceso de integración de componentes que se requiere en los proyectos no es una tarea simple. La integración de software es un problema complejo sobre todo en sistemas que involucran código desarrollado por diferentes personas. Por esta razón es necesario contar con un entorno que garantice la adecuada integración de las partes de un proyecto y posibilite visualizar los resultados de una manera fácil y clara. En este marco la Integración Continua ofrece un esquema que permite realizar integraciones a medida que se lleva a cabo el desarrollo, generando incrementos pequeños y mostrando los resultados obtenidos. En este sentido el presente trabajo plantea un modelo cuya finalidad es construir una solución open source que implementa la Integración Continua, y permita elaborar software más fiables y almacenar de forma segura los códigos desarrollados que forman parte del software, así como sus versiones anteriores. En la Universidad Central “Marta Abreu” de las Villas existe un grupo de personas interesadas en el desarrollo de este tipo de software en beneficio de ellos. Con el objetivo de desarrollar este software en el servidor local de manera segura y un control sobre el mismo, teniendo la seguridad que los códigos desarrollados por otras personas se integren correctamente, llevando un registro de las modificaciones en donde se almacene fecha y usuario que realizó la misma y saber cuánto se ha avanzado en cuanto a los objetivos planteados. Con la implementación de esta tarea se crearía un entorno de trabajo muy fiable y local, agilizando el desarrollo de los proyectos como el ArduPlane (Unmanned Aerial Vehicle por sus siglas en inglés AUV). Un vehículo no tripulado es todo aquel medio capaz de realizar diferentes tipos de tareas sin la necesidad de contar con un tripulante humano. Los vehículos aéreos no tripulados UAV.

(10) INTRODUCCIÓN. 2. han cobrado una gran importancia en la industria aeronáutica debido a que son capaces de cubrir un gran número de necesidades y posibilidades no exploradas hasta hace bien poco. Gran cantidad de universidades y centros de investigación, tanto privados como públicos, realizan en la actualidad investigaciones con vehículos aéreos autónomos, destacándose los aviones por tener menor complejidad y ser más económicos. Entre las principales instituciones a nivel mundial que siguen su desarrollo e investigación se encuentran la NASA, la Agencia de defensa y seguridad de Suecia (FOI), el Instituto Tecnológico de Massachussets (MIT), la Universidad Tecnológica de Delft en Holanda, la Universidad de Aalborg en Dinamarca, la Universidad de Cranfield, en el Reino Unido, la Universidad de Stanford, la Universidad de La Florida, entre otros(Pineda, 2008). El desarrollo de los UAV en Europa ha avanzado considerablemente. En la actualidad, existen proyectos de colaboración entre varios países como Alemania, Francia y España para la investigación sobre aplicaciones de vigilancia utilizando UAV, aunque Estados Unidos sigue liderando el desarrollo mundial, acaparando aproximadamente el 72% de la inversión en investigación(CARMENATE, 2009). En la última década el auge de los UAV se ha tornado extraordinario y a pesar de que originalmente su desarrollo estuvo impulsado por actividades militares esto permitió abrir el camino para desarrollar los UAV civiles. En la actualidad, ejemplos significativos de ello son el FT-ALTEA, Mohajer, Luna X-2000, y dentro de los proyectos de código abierto desarrollados por la comunidad se encuentra el firmware libre APM (Ardu-Pilot-Mega) que se ejecuta en el hardware Ardupilot y proporciona capacidad autónoma completa a cualquier avión de ala fija. Situación del problema ¿Cómo implementar el proyecto ArduPlane en el servidor de integración continua del grupo GARP, teniendo en cuenta las políticas de desarrollo y seguridad implementadas a nivel del grupo? Dada esta problemática es que surge este trabajo de diploma, en el cual se desea implementar en la Universidad Central “Marta Abreu” de las Villas (UCLV) el proyecto ArduPlane en el servidor de integración continua del Grupo de Automatización, Robótica y Percepción (GARP) donde se trabajaría en la red local para el desarrollo de software. Por otro lado, surge.

(11) INTRODUCCIÓN. 3. la necesidad de investigar cuáles serían las opciones más fiables y adecuadas para el servidor existente en la UCLV para que éste cuente con cierto grado de seguridad acorde con la política de desarrollo del GARP y de simuladores que prueben que las modificaciones que se le haga al software no perjudiquen la calidad del mismo. Objetivos: Objetivo general: Implementar el proyecto de ArduPlane en el servidor de integración continua existente en el grupo GARP.. Objetivos específicos:  Obtener todos los componentes necesarios para la correcta implementación del software en el servidor local.  Agregar el código al servidor y verificar su correcto funcionamiento.  Realizar pruebas de modificación al software y obtener nuevas versiones del mismo empleando el servidor local.. Posibles resultados: Con este proyecto se pretende desarrollar el software ArduPlane con una buena calidad, en el menor tiempo posible y más económico, debido a que se contará con mayor cantidad de desarrolladores trabajando de forma independiente, sin riesgos de conflictos entre los códigos desarrollados por cada programador, encargándose de esto el servidor. Se lograría el desarrollo local para este software y con un sistema de seguridad adecuado permitiendo restringir las personas que podrán acceder a él. También constará de un control de tarea, facilitando la organización en el trabajo. Además, minimiza los riesgos de integración, soporta el diagnóstico rápido de fallas y aportará buenas prácticas de desarrollo..

(12) INTRODUCCIÓN. 4. Impacto posible: Se impulsa el desarrollo del software de los vehículos no tripulados como cualquier otro de forma local, de acuerdo a las necesidades que se requieran, lo cual resulta más viable a las condiciones de nuestro país. Ya que permitirá optimizar el consumo tan grande de internet que requeriría desarrollar este tipo de software y además, colaborar con el desarrollo del software de los vehículos no tripulados que se podrán poner en marcha para usos e intereses del país.. Aplicabilidad: Los resultados de investigación poseen una aplicación práctica y teórica de gran trascendencia para todos los especialistas, investigadores y diseñadores del GARP, ya que la infraestructura del servidor permitirá trabajar en el desarrollo de este software y en otros, que se desee adaptar, mejorando y facilitando la calidad de trabajo de los investigadores.. Viabilidad: Para el desarrollo de este trabajo se encuentra disponible abundante información actualizada, así como asesoramiento de personal altamente calificado con vasta experiencia en el tema. También se dispone de un servidor profesional el cual permitirá albergar herramienta especializada que permita auxiliar el desarrollo de este trabajo, así como realizar todas las pruebas, revisiones y verificaciones que se requieran. Organización y estructura del trabajo de diploma: El trabajo de diploma se estructura en Introducción, tres capítulos, conclusiones, recomendaciones, referencias bibliográficas y anexos. CAPÍTULO I: Se presentan antecedentes teóricos de este trabajo así como una recopilación de soluciones propuestas en la literatura a los diferentes problemas planteados. CAPÍTULO II: Se realizarán las adaptaciones necesarias a la infraestructura del servidor del GARP para el desarrollo del software ArduPlane y se describirán los cambios hechos en la misma con base en los antecedentes teóricos presentados en el Capítulo I..

(13) INTRODUCCIÓN. 5. CAPÍTULO III: Se analizarán los resultados obtenidos en las pruebas realizadas al servidor mediante el uso de herramientas de programación sobre el software ArduPlane..

(14) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 6. CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. La aparición de nuevas tecnologías, así como el propio desarrollo del mercado y evolución de las estrategias de negocio han obligado a los especialistas e ingenieros de sistemas a adoptar nuevas metodologías y prácticas de desarrollo de software para lograr mayor agilidad, productividad y satisfacción en sus clientes. A su vez, el uso de sistemas basados en microcontroladores y plataformas en tiempo real para. determinadas aplicaciones se hace más frecuente aprovechándose su potencia de cómputo, bajo costo, bajo consumo energético, versatilidad y robustez, especialmente en tareas que demanden restricciones de altas frecuencias de muestreo, complejos algoritmos de control, integración y comunicación con hardware, sensores, actuadores, etc. Estos sistemas embebidos pueden realizar funciones que van desde el control y monitoreo de nivel de un tanque(Voord and Williams, 2008), hasta la completa automatización de un vehículo autónomo no tripulado(Martínez and Rodríguez, 2012). En este capítulo se tratan aspectos generales sobre los servidores de integración continua y servidores de control de versiones más conocidos, sus características, así como una breve descripción de ellos y otros aspectos para la comprensión de los mismos. También se hace énfasis en el desarrollo de la infraestructura del software del GARP. 1.1. Software de control de versiones. Un sistema de software de control de versiones es un grupo de aplicaciones pensadas y desarrolladas para gestionar de forma ágil los cambios en el código fuente de un desarrollo actual, y poder revertirlos con seguridad. Este ámbito, últimamente, ha sido ampliado desde el concepto control de versiones, llegando al concepto configuración y manejo de aplicaciones (software configuration management), en el que se engloban todas las.

(15) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 7. actividades que pueden realizarse por un equipo sobre un desarrollo, documentos, ofertas, dibujos, esquemas, entre otros. Una versión, revisión o edición de un producto, es el estado en el que se encuentra dicho producto en un momento dado de su desarrollo o modificación. Los sistemas de control de versiones facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas. Los orígenes del sistema provienen de la época en que apenas existían redes de ordenadores. En esta época, los ficheros se gestionaban de manera individual, y ya se encontraban algunas herramientas predecesoras:  Revision Control System pos sus siglas en inglés (RCS): almacenaba la última versión y sus diferencias con la anterior. Permitía la recuperación eficaz del fichero origen.  Source Code Control System por sus siglas en inglés (SCCS): gestiona diferencias entrelazadas entre ficheros, que permiten generar versiones como un conjunto de subrevisiones. Existen herramientas que dan soporte al control de versiones con el fin de facilitar su uso y llevar un control en todo momento. Estas herramientas se denominan Sistemas de Control de Versiones (VCS por sus siglas en ingles Version Control System). Comúnmente funcionan como aplicaciones independientes, pero el control de versiones también está incluido en varios tipos de software, como pueden ser los procesadores de texto y hojas de cálculo(Bahón, 2014). Un sistema de este tipo presenta las siguientes características:  Sistema de almacenamiento para gestionar distintos elementos  Realizar cambios sobre los elementos almacenados.  Registro histórico de las acciones realizadas que permita retroceder a un estado anterior del producto, ver diferencias entre estados, etc. Para comprender a fondo el funcionamiento de los sistemas de control de versiones a continuación se describen brevemente los términos usados en este contexto. Éstos pueden.

(16) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 8. variar en función del VCS utilizado. Sin embargo la mayoría es de uso común. Para entender mejor del tema es necesario conocer los siguientes conceptos.  Repositorio: es el lugar donde se almacenan los datos actualizados y el histórico de cambios.  Revisión: identifica la versión o estado del conjunto de elementos. Hay sistemas que los identifican con contadores (ej. Subversión) y otros mediante códigos. (ej. Git usa códigos SHA-1)  Directorio de trabajo: es el directorio cuyo contenido de ficheros/directorios corresponden a la revisión en la que el repositorio está colocado en ese instante.  Etiquetas o (tags): permiten identificar con un nombre preciso una confirmación. Se utilizan para marcar puntos de importancia, que estén accesibles de manera sencilla. Por ejemplo para marcar la versión del software en una confirmación determinada. (ej. v0.7, v1.0, etc.)  Ramas (branches): estas son conjuntos de confirmaciones, que reflejan la evolución de un proyecto. Una rama puede ser bifurcada o ramificada en un instante de tiempo, de manera que desde ese momento en adelante se tienen dos copias (ramas) que evolucionan de forma independiente siguiendo su propia línea de desarrollo. Este procedimiento se puede realizar tantas veces como sean necesarias. La ventaja de desarrollar con ramificaciones es que, permite crear ramas de pruebas que contengan código pendiente de evaluación, crear estas dedicadas a nuevas funcionalidades, ramas de corrección de errores, etc.  Despliegue (clone, check- out): un despliegue crea una copia de trabajo local desde el repositorio.  Confirmación (commit): se utiliza para almacenar el estado de los cambios realizados en la copia de trabajo en el repositorio, el resultado es una revisión..

(17) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 1.1.1. 9. Flujo de trabajo. Una de las características más interesantes de los sistemas de control de versiones es la posibilidad de asentar flujos de trabajo en el grupo de desarrollo. Estos flujos de trabajo indican cómo se relacionan los diferentes usuarios para colaborar entre sí. Los sistemas centralizados (modelo cliente-servidor), como es lógico, restringen de buena manera la forma en la que los usuarios colaboran, en cambio, los sistemas distribuidos permiten una gran flexibilidad incorporando el concepto de que cada desarrollador puede contribuir y recibir contribuciones, lo que evidentemente resulta más colaborativo. El utilizar diversos flujos de trabajo permite trabajar con gestores de integraciones para ciertas partes críticas o de especial relevancia(Loeliger and McCullough, 2012). Sistemas de control de versiones centralizados Los sistemas centralizados se basan en una comunicación cliente-servidor, de forma que existe un único repositorio al que los usuarios acceden. Los usuarios obtienen una copia de éste en su máquina local sobre la que trabajar y una vez hayan realizado cambios sincronizarán sus cambios con los del repositorio. Este modo obliga a los usuarios del sistema a estar conectados al repositorio cada vez que necesiten actualizarlo(Chacon, 2009). Sistemas de control de versiones distribuidos En las herramientas distribuidas, en cambio, se sigue un formato de igual a igual, en el que en principio no existe un repositorio central. Cada desarrollador tiene el suyo en el que desarrollará el proyecto. Esto permite a los usuarios intercambiar información entre ellos. Este enfoque permite distribuir el trabajo dando la oportunidad de que los desarrolladores se organicen por grupos para desarrollar partes concretas del código, y finalmente unificar todo(Chacon, 2009). Cada tipo de VCS posee sus ventajas: Ventajas de los distribuidos  Se puede trabajar sin conexión (para hacer un commit no hay que estar conectado al repositorio central). Esto produce una mayor autonomía y una mayor rapidez.  Se pueden crear ramas locales que no afecten a los demás usuarios..

(18) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 10.  Un sistema distribuido es más ágil que uno centralizado, ya que gran parte del trabajo se reparte entre cada máquina. En los centralizados, la mayor parte de trabajo la debe realizar la misma máquina, es decir el repositorio central. Ventajas de los centralizados  Siempre se tiene una versión actualizada del proyecto en desarrollo.  Fácil de aprender y utilizar. 1.1.2. Ramificación (branching). Las ramas son una herramienta que nos permite flexibilizar el método de colaboración de los desarrolladores proporcionando diferentes espacios de trabajo con diferentes versiones que agilicen el desarrollo del software. Se pueden distinguir dos posibilidades básicas: ramas puntuales o ramas estables de larga duración(Aniszczyk, 2011). En las puntuales, estas representan funcionalidades concretas que necesitan un desarrollo apartado del general. También son conocidas como ramas de soporte, y permiten al desarrollador centrarse exclusivamente en el desenvolvimiento de una característica concreta, y cuando finaliza su desarrollo, se fusiona con el proyecto general o con ramas superiores. La fusión se realiza solo si se está totalmente seguro de que la característica funciona en cualquier caso, es decir, no se sigue ningún orden. Esto provoca que las ramas superiores no sean “ensuciadas” con modificaciones relativas a una funcionalidad concreta. Existen varios subtipos de ramas puntuales: ramas de nueva funcionalidad (topic branch o feature branch), para corregir error (hotfix branch) o de versión (release branch). Estas últimas permiten dar soporte a una nueva versión de producción controlando su contenido y proporcionando mantenimiento, correcciones y mejoras sobre ella. Por otro lado, las ramas estables o de larga distancia suelen tenerse siempre abiertas, representando diversos grados de estabilidad. Normalmente, existe una rama máster totalmente estable que se encuentra controlada y disponible para entornos de producción. A partir de este punto, el resto de ramas son más inestables y se pueden calificar como ramas beta, alpha, unstable, dev y experimental, que son aquellas sobre las que se va trabajando. Cuando se alcanza un cierto grado de estabilidad mediante unos requerimientos establecidos,.

(19) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 11. se fusionan los cambios confirmados con la rama máster. A continuación en la Figura.1.1 se muestra un ejemplo de ramificación.. Fig.1.1. Ejemplo de ramificaciones. 1.1.3. Alternativas de software de control de versiones. En la actualidad, existen tanto soluciones de código abierto como de código privado, con diferentes tipos de licencia y filosofías, gratis y de pago, y adaptadas tanto a modelos centralizados como a modelos distribuidos. A continuación se describen las alternativas más utilizadas y conocidas en el siguiente análisis. Concurrent Version System (CVS) Este sistema está basado en el modelo centralizado. Es gratuito, fue desarrollado por GNU (GNU is Not Unix) y es muy popular dentro del mundo del software libre. Actualmente se encuentra obsoleto y está siendo sustituido por alternativas más actualizadas como Subversión. Su utilización se extendió debido a la posibilidad de un manejo eficaz mediante comandos desde consola. Posee algunas limitaciones tales como que los ficheros no pueden ser renombrados y posee un soporte discreto de ficheros Unicode con nombres de archivo no ASCII (Código Estándar Estadounidense para el Intercambio de Información). Por el contrario, el gran uso que ha tenido y su popularidad hacen que exista un software que complemente este sistema. Subversion (SVN) Basado en el modelo centralizado. Es gratuito y es también conocido como SVN. Posee una característica importante respecto a CVS y es que todo el repositorio tiene un único número.

(20) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 12. de versión que identifica un estado común de todos los ficheros en un instante determinado. Es uno de los sistemas más reconocidos por la comunidad del software libre y se utiliza en proyectos de gran envergadura como Apache, Django o FreeBSD. Además, existen servicios de alojamiento que lo proporcionan como SourceForge, Google Code, CodePlex o RedIRIS(Subversion, 2012). Git Basado en el modelo distribuido. Fue creado por Linus Torvalds, y por lógica, es utilizado en el grupo de programación del núcleo Linux. Actualmente recibe contribuciones de alrededor de 280 programadores. Es gratuito y utiliza la licencia GPL (Licencias Publicas Generales). Su diseño está inspirado en BitKeeper y en Monotone, ambas alternativas de pago, mezclado con la experiencia de su creador y a la vez creador de Linux, ya que lleva varios años manteniendo una enorme cantidad de código distribuido y gestionado por muchos desarrolladores, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación. Presenta características como fuerte apoyo al desarrollo no-lineal, es decir, rapidez en la gestión de ramas y diferentes versiones, posibilidad de publicación de almacenes de información mediante HTTP, FTP, rsync o protocolo nativo, ya sea a través de cifrado SSH o sin cifrar, emulación de servidores CVS, uso directo de repositorios Subversión y SVK, gestión eficiente de proyectos grandes por su optimización de velocidad de ejecución en la gestión de diferencias entre archivos, notificaciones obligatoria de cambios posteriores a versiones previas a un cambio, evita coincidencia de ficheros diferentes en un único nombre, ya que los renombrados se basan en similitudes entre ficheros, almacenamiento periódico en paquetes y trabajo en base a cambios de proyecto en vez de cambios de fichero(Loeliger and McCullough, 2012). Microsoft Visual Studio Team Foundation Server Basado en el modelo centralizado. Desarrollado por Microsoft. Está integrado dentro del entorno de desarrollo Microsoft Visual Studio, y, por lo tanto, está orientado a desarrollos en tecnologías Microsoft (NET). Evidentemente, su licencia es EULA y es software privado de pago. Ofrece una forma eficaz, integrada y gratuita para quien desarrolle en entornos.

(21) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 13. Microsoft de disponer un sistema de control de versiones para un equipo de desarrollo de cualquier tamaño. Team Foundation Server ofrece funciones de seguimiento de elementos de trabajo, además del control del código fuente. Team Foundation Build está incluido y se trata de un sitio web del proyecto de equipo, con generación de informes y administración de proyectos. Además, Team Foundation Server, incluye un almacén de datos donde se guardan las generaciones y las herramientas de pruebas. Cada empresa, según sus necesidades, puede implementar otros servidores. Un servidor de Team Foundation Server se compone de un servidor a nivel de aplicación con servicios web, y un servidor de nivel de datos compuesto por varias bases de datos de SQL Server. El servicio de control de código fuente presenta una serie de características, una de ella es, que como conjunto completo de control de versiones cuenta con protecciones de un cambio al mismo tiempo, ramificaciones y recombinaciones optimizadas, aplazamiento de cambios, administración de ramas y coordinación de cambios (con un rol específico de administrador especializado) y directivas de protecciones(MSDN, 2012). Plastic SCM Es de las pocas soluciones propietarias de pago basadas en el modelo distribuido, donde claramente gobiernan los sistemas de código abierto gratuitos, y por ello es que proporcionan una versión gratuita para equipos de desarrollo de máximo 15 miembros. Está desarrollado bajo licencia propia, propietaria por la empresa española Codice Software. Sus objetivos son dar un mayor soporte al desarrollo paralelo, creación de ramas, integración de ramas, seguridad y desarrollo distribuido. Está desarrollado bajo la plataforma .NET(Plastic, 2012). Presenta características tales como que sus ramas son creadas como objetos vacíos y solamente cuando un fichero es modificado se asigna una nueva versión a la rama, ramas inteligentes en las cuales el usuario puede definir una jerarquía con soporte de los mecanismos de herencia de etiquetas, seguridad basada en listas de control de acceso con 25 tipos de permisos diferentes y espacios de trabajo configurables con mapeo de contenidos..

(22) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 1.1.4. 14. Comparativa. A continuación, se expone en la Tabla 1.1 una comparativa de las alternativas estudiadas según su precio, modelo de diseño, licencia, ventajas e inconvenientes. Tabla 1.1. Comparativa entre sistemas de control de versiones. CVS. Subversion. Git. Visual Studio Fundation Server. GPL. Apache/BSD. GPL. Microsoft EULA. Plastic SCM. Propietaria. Gratis. Gratis. Gratis. Desde 1283.65€. Gratis hasta 15 usuario. Después $279 por usuario extra.. Centralizado. Centralizado. Distribuido. Centralizado. Distribuido. Ventajas. Muchas herramientas disponibles. Cuenta con popularidad y soporte.. Cuenta con popularidad y soporte. Gran variedad de clientes. Sencillez e integración con las nubes de IDEs. Bloqueo de fichero. Ahorro del ancho de banda.. Integración Popularidad. Visual Studio. Pensado para Compatibilidad proyectos con tecnología grandes. .NET. Compatibilidad Generación de con SVN y informes. CVS. Ideal Protección de para el cambios al desarrollo no mismo tiempo. lineal. Rapidez Ramificaciones en el manejo optimizadas. de sus ficheros. Aplazamientos Notificación de de cambios. cambio. Gestor de ramas.. Soporte empresarial. Soporte a diferentes IDEs. Solo se asigna a la rama de ficheros modificados. Ramas inteligentes con herencia. Visionado de ramas y árbol de revisión en 3D. Seguimientos de fusiones..

(23) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 15. Desventajas Soporte de renombrado y gestión de ficheros binarios. Obsoleto.. Manejo de orden de cambios de ramas. Funciones de renombrado no completa. Menor soporte de herramientas para IDEs en sistemas operativos.. No compatibilidad con otros entornos fuera de Visual Studio.. Elevado precio para grupos de desarrollos grandes.. Para la realización de este trabajo de diploma, se cuenta con el servidor de control de versiones Git, perteneciente al GARP, el cual consta con todos los requerimientos necesarios para el desarrollo de esta aplicación según el análisis bibliográfico realizado. Git no es un sistema de control de versiones centralizado, aunque si se desea puede destinarse un repositorio central. La historia completa de los impactos en el repositorio existe en la máquina local de los desarrolladores donde se ha clonado una copia local del repositorio(McCullough, 2010). Acciones como clonar un proyecto (clone), adicionar ficheros, revisar el historial, comparar, realizar impactos locales (commit), actualizar una copia local (pull), enviar los cambios a un servidor central (push), crear nuevas ramas, mezclar ramas. Son acciones muy comunes al trabajar con Git y además de muy fácil ejecución al tan solo con disponer de una consola de comandos o clientes como TortoiseGit. 1.2. Sistemas de Integración Continua. Los proyectos de desarrollo de software requieren de un gran número de archivos que necesitan ser integrados para construir un único producto. Esto puede consumir un tiempo considerable del proyecto pues esta tarea es reiterativa y porque los códigos confeccionados por los diferentes desarrolladores pueden causar conflictos con los anteriores implementados. De acuerdo a Fowler(Fowler, 2009), la integración continua es una práctica del desarrollo de software en donde los miembros de un equipo integran su trabajo frecuentemente, usualmente cada persona integra al menos diariamente, existiendo múltiples integraciones por día. Cada integración es verificada por un proceso de construcción automatizado (se incluye la ejecución de pruebas) que detecta errores de integración tan rápido como es posible. La práctica internacional ha demostrado que este enfoque permite reducir.

(24) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 16. significativamente los problemas de integración y permite a un equipo desarrollar software cohesivo más rápidamente. La forma más habitual de implementar el concepto de la integración automática, es trabajar con un repositorio donde los desarrolladores depositen su trabajo, es decir, un sistema de control de versiones. A continuación, se utiliza una aplicación para la planificación de los test, la descarga y compilación del código fuente y la monitorización de su ejecución. Estas aplicaciones son el núcleo del sistema y están diseñadas siguiendo las directrices de la integración continua. Ejemplos de estas aplicaciones son Bamboo, Continuum, Hudson, Jenkins, CruiseControl o Team Foundation Build (este último solo para Microsoft.NET). Según la plataforma de desarrollo que se esté empleando, existe la posibilidad de utilizar herramientas que facilitan la compilación y ejecución de un proyecto, tales como Ant o Maven para Java, Nant o MSBUILD para Microsoft.NET, Makefiles para C/C++ en GNU/Linux, entre otras, aunque existen otras herramientas que realizan pruebas unitarias como JUnit para Java o PyUnit para Python que pueden funcionar como complementos ideales para los sistemas de integración. Aparte de esto, y según el sistema de integración empleado, pueden existir extensiones, plugins y complementos que aumenten la compatibilidad, funcionalidad y opciones del sistema. Fowler propone una serie de actividades para llevar a cabo esta práctica, que son(Fowler, 2009):  Mantener un único repositorio de artefactos.  Automatizar el proceso de construcción.  Incluir la automatización de pruebas en el proceso de construcción.  Enviar cada día al repositorio las últimas versiones de artefactos.  Por cada envío de códigos se deberá construir la línea base del sistema.  Mantener el proceso de construcción rápido.  Probar en un ambiente de pruebas igual al de producción.  Hacer de una manera fácil que cualquier persona obtenga la última versión del ejecutable..

(25) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 17.  Que todo mundo vea lo que está sucediendo.  Automatizar el proceso de despliegue. Propósitos de la Integración Continua:  Ser capaces de controlar la salud del proyecto durante todo el ciclo de desarrollo.  Que el código que hay en nuestro repositorio funcione.  Invertir menos tiempo en integración.  Incrementar en la visibilidad del proceso de retroalimentación inmediato.  Reducir los riesgos del proyecto.  Dedicar menos tiempo a la creación de versiones.  Incrementar la confianza entre los usuarios de negocios y el equipo de proyecto. 1.2.1. Método de trabajo. El método de trabajo se resume en los siguientes puntos:  Un desarrollador termina de implementar una nueva característica; la misma debe ser rápida y sencilla, ya que un concepto de la integración continua es realizar chequeos sobre código para asegurar su estabilidad y que bajo ninguna circunstancia existirá un error en ese punto. En otras palabras, si funciones sencillas no fallan, los cimientos del resto serán lo suficientemente estables y se ahorrará tiempo de búsqueda de errores, que se perdería al implementar todo sin realizar pruebas intermedias.  La característica terminada se añade o actualiza en el sistema de control de versiones: en este punto, el sistema de integración puede detectar el cambio o bien estar configurado para ejecuciones cíclicas en un intervalo de tiempo. En cualquier caso, el sistema de integración descarga una copia de la última versión del proyecto.  Comienza la prueba o chequeos: el sistema de integración compilará la última versión y la ejecutará mediante chequeos que estimulen la aparición de errores, mientras tanto, monitorizará todo e informará de errores de compilación, ejecución o resultados no esperados..

(26) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 18.  Informe de la prueba: si el sistema determina un resultado incorrecto, se notificará según su configuración (existen multitud de opciones: aviso sonoro, e-mail, entre otros), en caso contrario, notificará que el nuevo código ha sido integrado con éxito y es estable. 1.2.2. Ventajas. Existen varias ventajas en el uso de este método de trabajo:  Los desarrolladores pueden detectar y solucionar problemas de integración de forma continua, evitando largas pérdidas de tiempo de depuración cuando se acercan las fechas de entrega.  Disponibilidad constante de una compilación para pruebas, demos o lanzamientos anticipados.  Ejecución inmediata de las pruebas unitarias de forma automática.  Monitorización continua de las métricas de calidad del proyecto. La integración continua proporciona automatización y estabilidad, ahorra tiempo y dinero en realizar pruebas al final y rebuscar donde se encuentran los errores y proporciona un sistema de control del código fuente. Por sus ventajas, no es extraño que empresas importantes apuesten por este modelo como Microsoft, IBM u Oracle. 1.2.3. Desventajas. Evidentemente, existen claras desventajas tales como(Neches, 2012):  Los problemas de integración se deben detectar cuando son insertados en el código, pero esto puede originar que la integración en conjunto del proyecto no sea la más optimizada. Por lo que es necesario realizar siempre pruebas totales al final de su desarrollo.  Los desarrolladores no poseen el hábito de actualizar el repositorio con frecuencia.  La compilación de código se puede demorar y tomarse un impedimento para la construcción e integración continua del código fuente..

(27) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 19.  Estos sistemas benefician el correcto funcionamiento, no la optimización, clave en determinados campos.  La instalación, mantenimiento de estos sistemas y la realización de pruebas conlleva una buena parte del tiempo de los desarrolladores, o mantener una persona dedicada. 1.2.4. Alternativas de software de Integración Continua. En este apartado, se analizan las alternativas más conocidas en entornos de integración continua. CruiseControl Se presenta como un sistema de integración continua, y como un framework para crear procesos de compilación continuos personalizados. Está desarrollado en Java, es gratuito y de código abierto bajo licencia de tipo BSD. Provee una interfaz web para la administración, gestión y monitorización. Posee un sistema de extensiones para soportar una buena variedad de plataformas, herramientas de compilación, esquemas de notificación, entre otros, aunque inicialmente soporta Ant, NAnt, Maven, Phing, Rake y Xcode; además de línea de comandos de consola del sistema operativo y scripts. Existen versiones para Ruby y plataforma .NET (CruiseControl .NET)(CruiseControl, 2012). Su desarrollo original partió de ThoughtWorks, surgiendo como una necesidad de una solución de integración continua para sus proyectos. Posteriormente, debido a su utilidad, se amplió su desarrollo como una aplicación independiente. Jenkins Es un sistema de integración continua desarrollado en Java bajo licencia MIT y Creative Commons. Es gratuito y de código abierto, además de multiplataforma. Está basado en el proyecto Hudson, ya que es un clon o, simplemente, un cambio de nombre, ocasionado por una disputa con Oracle, ya que esta reclama los derechos de uso de la marca Hudson. Jenkins está construido como un servlet (es una clase del lenguaje de programación java) para Apache Tomcat, aunque puede instalarse y funcionar como un servicio del sistema independiente. Soporta CVS, Subversion, Git, Mercurial, Perforce y Clearcase, sin contar extensiones, y puede ejecutar Ant y Maven, aparte de scripts y ficheros de procesamiento por lotes de Windows o comandos de consola. Fue creado por Kohsuke Kawaguchi como una alternativa.

(28) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 20. a CruiseControl y otros sistemas existentes, recibiendo en 2011 un premio Google-O’Reilly Open Source Award(Jenkins, 2012). Posee una gran variedad de extensiones y complementos que le hacen soportar casi cualquier opción de desarrollo disponible, varias maneras de notificar errores, lograr la integración con bases de datos, personalizar la interfaz, y hasta colocar juegos en el sistema y demás curiosidades. Por lo tanto, la compatibilidad de Jenkins con cualquier plataforma de desarrollo está asegurada, ya que es posible crear extensiones a medida o realizar scripts personalizados para su ejecución(Smart, 2011). La interfaz gráfica de Jenkins consiste en un sitio web accesible con cualquier navegador. Permite administrar todo el sistema (extensiones, configuración, repositorios, opciones de sistema operativo, seguridad, entre otros), crear y gestionar proyectos y ciclos de compilación, monitorizar ejecuciones, consultar historiales, entre otros. Las opciones son muy variadas y provocan que el sistema sea totalmente flexible. Posee aplicación móvil para iOS y Android. Bamboo Es un sistema de integración continua desarrollado por Atlassian. Se distribuye bajo licencia propietaria, es multiplataforma y de pago; aunque dispone de versión gratuita para actividades no comerciales y de código abierto y posee descuentos para instituciones académicas. Bamboo soporta compilaciones en cualquier lenguaje de programación, utilizando cualquier herramienta de compilación tipo xUnit o Selenium, incluyendo soporte de Ant, Maven, makefiles, Microsoft .NET y comandos de consola del sistema operativo, al estilo de Jenkins. Permite integración con IDE basados en Eclipse o IntelliJ IDEA, además de Visual Studio(Atlassian, 2012). Continuum Es un sistema de integración continua, basado en un servidor y gestionado desde un servidor web, al estilo de sus competidores Jenkins o Bamboo. Está desarrollado por Apache, bajo lenguaje Java con la plataforma de gestión Maven, siendo totalmente integrado con ella. Se distribuye bajo licencia Apache 2.0 y es de código abierto y multiplataforma. Al igual que sus competidores más directos, es capaz de realizar compilaciones planificadas automáticamente e informar de errores mediante correo electrónico. Al igual que Jenkins o.

(29) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 21. Hudson, puede ejecutarse como una aplicación independiente o funcionar como un WAR introducido en un soporte de servlets. Aparte de la interfaz web de gestión, su configuración de proyectos se basa en un fichero XML, a través del cual se pueden añadir los proyectos deseados, y el sistema se encargará del resto, desde comprobar el repositorio de versiones a ejecutar las pruebas unitarias. Soporta CVS, Subversion, Clearcase, Perforce, Starteam, Microsoft Visual SourceSafe, CM Synergy, Bazaar y Mercurial, además de almacenar y mostrar los cambios en los sistemas de control de versiones para compilación. Es posible notificar resultados por e-mail, Jabber, Google Talk, Windows Live Messenger, entre otros. Las ejecuciones pueden realizarse mediante las herramientas Maven, Ant o a través de scripts de consola. Como características avanzadas, incorpora soporte para compilaciones paralelas y/o distribuidas. No permite la extensión de funcionalidades mediante plugins. Sin duda, un inconveniente que le perjudica en su desempeño, es un producto relativamente joven y que necesita tiempo de mejora. Sin embargo, posee una API XMLRPC para la interacción con aplicaciones externas(Apache, 2012). 1.2.5. Comparativa. A continuación, en la Tabla 1.2 se expone una comparativa de las alternativas estudiadas según su licencia y precio, compatibilidad con herramientas de compilación, compatibilidad con sistemas de control de versiones, procesos de comunicación externa, posibilidades de ampliación y soporte de procesamiento distribuido. El sistema empleado por el GARP es el Jenking, el cual se adecua a las exigencias del proyecto por las razones expuestas aquí:  Gratuito, fácil instalación y autoconfiguración.  Gran comunidad de soporte y extendido uso del sistema.  Compatibilidad con Git.  Posibilidad de instalarse como un servicio de Windows  Numerosas extensiones de funcionalidad de múltiples ámbitos (compilación, notificación, métricas, aplicaciones móviles, entre otras)..

(30) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 22. Tabla 1.2. Comparativa entre sistemas de integración continua.. CruiseControl. Jenkins. Bamboo. Continuum. Gratuito y de código abierto. Gratuito y de código abierto. Propietario(desde $10 hasta $1600 según las necesidades). Gratuito y de código abierto. Ant, NAnt, Maven, Phing, Rake, Xcode, .NET, Ruby, scripts y shell. Ant, Maven, scripts y shell. xUnit, Selenien, Ant, Maven, makefiles, Microsoft.NET, Eclipse, scripts y shell. Ant, Maven, scripts y shell. Accurev, Clearcase, CMSSynergy, jCVS, MKS, Perforce, Pvcs, StarTeam, Surversion, View CVS y CVS. CVS, Surversion, Clearcase, Perforce, Git, y Mercurial. Incluye framework. Comunicación externa HTTP y Java RMI. CVS, Surversion, Clearcase, Perfoce, CVS, Surversion, StarTeam, Perforce, Git y Microsoft Visual Mercurial Studio, Bazaar y Mercurial. Comunicación externa bajo API Comunicación XML, aplicaciones externa bajo API móviles, Android y REST iSO. Posibilidades de Posibilidades de Posibilidades de extensión con extensión con extensión con plugins. Desarrollo plugins. Desarrollo plugins. Desarrollo bajo Java bajo Java con Atlassian SDK Gestión de ejecuciones distribuidas del sistema. Distribución total, y compatibilidad Compilación y con Amazon EC2 testeos distribuidos para cómputo y Amazon S3 para almacenamiento. Comunicación externa bajo API XMLRPC. No permite extensiones. Compilaciones distribuidas.

(31) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 1.3. 23. Infraestructura del grupo GARP. Aunque en Cuba el desarrollo de los UAV es bastante escaso, debido a las disímiles aplicaciones que estos poseen, es de interés del Grupo de Automatización, Robótica y Percepción (GARP) el desarrollo e implementación de autopilotos para estos vehículos. Estos autopilotos se implementan utilizando tecnología de bajo costo. El grupo de investigación GARP desde el 2008 se ha dado a la tarea de investigar en campos relacionados con vehículos autónomos. Los resultados obtenidos están reflejados en tesis de ingeniería, en las cuales se plantean los distintos problemas a los que se han enfrentado en el grupo para establecer una lógica para el modelado matemático de estos vehículos aéreos de seis grados de libertad(Pineda, 2008). Los primeros resultados obtenidos de manera práctica en el grupo utilizando los pasos de modelado, identificación y sintonías de controladores basados en modelo, a través de experimentos desarrollados por el GARP, se obtuvieron en el avión N606LS. A partir de la demanda de software y hardware a producir en el grupo de investigación y desarrollo GARP para enfrentar las solicitudes y requisitos que se desean se hace indispensable la adopción de una metodología de desarrollo que permita:  Integración de investigadores, desarrolladores de hardware y software, clientes, entre otros, en un equipo multidisciplinario donde todos puedan realizar sus tareas en un entorno común de colaboración.  El código del producto esté visible y disponible para todos los miembros del equipo y gestionado de forma segura.  Realimentación a los desarrolladores de forma rápida sobre errores de construcción, integración, pruebas, entre otros.  Entorno de construcción automatizado, unificado, flexible y de poco esfuerzo en mantenimiento.  Los artefactos generados, producto de la construcción (Integración Continua), estén centralizados, actualizados y listos para ser usados sin necesidad de construirlos nuevamente..

(32) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 24.  La planificación de las iteraciones estén disponibles y públicas para todos los integrantes del equipo. Para lograr estos objetivos se hace necesario modificar costumbres y hábitos en el equipo de desarrollo, así como implantar un soporte tecnológico que permita que el software que se está desarrollando cumpla el ciclo de vida mostrado en la Figura.1.2.. Planificación Refactorización. Integración Continua Pruebas Funcionales. Diseño. Codificación Pruebas Unitarias. Versionamiento Código Fuente. Figura.1.2. Ciclo de vida de desarrollo El presente trabajo propone implantar una infraestructura tecnológica, mostrada en la Figura.1.3, más adecuada y que permita una mejor comunicación y colaboración en el equipo de desarrollo, así como lograr automatizar tareas repetitivas que disminuyan el esfuerzo en gestión del código fuente, construcción, integración, pruebas, empaquetado, entre otros, y poder emplear de forma más eficiente los recursos humanos disponibles en tareas propias de desarrollo e incremento del producto(Contino et al., 2015)..

(33) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 25. Figura1.3. Infraestructura propuesta. El software de control de versiones del GARP, cuenta con una herramienta Gerrit, la cual se emplea para la revisión de código. Su principal característica es actuar como un filtro. Se utiliza junto al sistema de control de versiones Git. Gerrit es el que permite a los contribuyentes autorizados enviar cambios al repositorio Git y que lo puedan subir después de su revisión. Los contribuyentes pueden obtener su código revisado y obtener sus cambios rápidamente a través del sistema(Aniszczyk, 2011). Gerrit se usa con dos fines. En primer lugar, el contribuyente puede cargar cambios en Gerrit, y segundo, los aprobadores y revisores pueden completar un proceso de revisión con el navegador web. Los cambios se cargan con el comando git push. El proceso de revisión incluye los siguientes pasos:  Revisar los cambios.  Publicar comentarios.  Aprobar o abandonar cambios..

(34) CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA. 26. El sistema de integración continua es Jenkins. Por lo que se puede decir que el servidor del grupo GARP cuenta con todas las condiciones creadas para la realización del trabajo de diploma. 1.4. Consideraciones parciales del capítulo. El uso de un servidor de integración continua (Jenkins) permitirá obtener productos de mejor calidad, gracias a la detección temprana de los errores y en el menor tiempo posible, ya que podrán trabajar varios desarrollador en un mismo software e incluso en un mismo fichero de código, sin preocuparse de errores de integración con el desarrollo que esté haciendo el otro, logrando una mayor cohesión del trabajo. El software de control de versiones Git es una herramienta muy potente que cuenta con las condiciones para asegurarnos que la infraestructura de desarrollo se la más adecuada y mejor posible. Después del análisis de la bibliografía especializada se puede garantizar que GARP cuenta con las condiciones de hardware y software para el desarrollo e implementación del ArduPlane de forma local..

(35) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 27. CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE. ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES.. En este capítulo con los conocimientos adquiridos en las literaturas especializadas se pretende implementar el proyecto ArduPlane en el servidor de integración continua del grupo GARP. Para ello se necesita de un repositorio en un servidor de control de versiones que en este caso es el Git. Se muestran las herramientas para realizar dicha tarea, siendo ésta el objetivo que se espera alcanzar, y de esta manera queda descrito el espacio de trabajo. También quedan plasmados todos los comandos y pasos a seguir para trabajar con estos servidores.. 2.1. Entorno de trabajo. El entorno de ejecución comprende el hardware y el software sobre el que se desarrolla la aplicación. Provee servicios para un programa en ejecución. En este se cuenta con herramientas de software tales como un servidor de integración (Jenkins), un servidor de control de versiones (Git), con un servidor de verificación de código (Gerrit) y Mantis; los mismos están montados en un servidor profesional para así conformar el entorno de trabajo. También se cuenta con el propio software del avión que se va a desarrollar en su última versión ArduPlane-2,74b. El servidor de integración continua que se cuenta en este entorno es el Jenkins con una dirección de IP 10.12.112.62:8080/jenkins. El servidor de control de versiones es Git el cual presenta una dirección IP y es 10.12.112.62, pero no se puede acceder directamente, porque.

(36) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 28. el medio de acceso es a través de Gerrit. Se cuenta también con la herramienta Gerrit que éste posee la siguiente dirección de IP 10.12.112.62/gerrit/. Y por último queda el Mantis con una dirección de IP 10.12.112.62/mantis. De esta forma está conformado el espacio de trabajo y como acceder a cada una de las herramientas planteadas. 2.2. Prerrequisitos necesarios. Después de un análisis previo del software que se va a utilizar, se puede apreciar que el lenguaje de programación que se utiliza es C++ y cuenta con los archivos makefile necesarios para poder trabajar en el nodo principal de Jenkins estando el mismo montado con un sistema operativo Linux y es adecuado para su uso en el servidor, de no ser así se necesitaría otra serie de requisitos, como instalación de plugin o utilizar el nodo esclavo el cual está montado en Windows. Luego se procede a instalar los prerrequisitos del software contenidos en una carpeta propia de él, esto instala el espacio de trabajo con todas las variables globales que se van a usar para la ejecución del proyecto en GNU Linux. Este paso es necesario hacerlo en la máquina que se vaya a correr el software, solo se realiza una vez y después es posible compilar y ejecutar el software, empleando el compilador de C/C++ en Linux. Para la instalación de los prerrequisitos del software, se accede al servidor donde se va a compilar el programa, luego se copia la carpeta Tools en el servidor y se accede a Tools/scripts. Para la instalación se emplea el comando ./install-prereqs-ubuntu.sh que se encarga de instalar el entorno de trabajo para Ubuntu en el servidor, estos prerrequisitos solo instalan en la maquina las bibliografías y variables globales necesarias para la ejecución de proyectos ArduPlane. Hecho esto se recomienda depurar el software para no subir carpetas innecesarias al repositorio de Git que se va a crear evitando tener archivos innecesarios en el repositorio. El software presenta la estructura:.

(37) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 29. Debido a que las demás carpetas pertenecen a otros proyectos llevados a cabo por Ardupilot que no son de nuestro interés para el proyecto ArduPlane:. Una vez realizado esta serie de pasos se han sentado las bases para comenzar con la creación de un proyecto en el servidor de integración continua. A continuación se procederá en dos pasos, primero con el servidor de control de versiones y después con el servidor de integración continua. 2.3. Servidores de control de versiones Git. Es muy importante asimilar el conocimiento de cómo trabaja Git, para que sea mucho más fácil usarlo de manera eficaz. Éste modela sus datos como un conjunto breve en un mini sistema de archivos. Cada vez que se confirma un cambio, o guarda el estado del proyecto en Git, él básicamente hace una foto del aspecto de todos los archivos en ese momento, y guarda una referencia a ese instante. Para ser eficiente, si los archivos no se han modificado, Git no almacena el archivo de nuevo, solo un enlace al archivo anterior idéntico que ya tiene almacenado (Ver esto en la Figura 2.1)(Chacon, 2009)..

(38) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 30. Figura.2.1. Almacenamiento de la información de Git a lo largo del tiempo. Cuando se realizan acciones en Git, casi todas ellas solo añaden información a su base de datos. Es muy difícil conseguir que el sistema haga algo que no se pueda deshacer, o que de algún modo borre información. Como en cualquier VCS, se puede perder o estropear cambios que no se han confirmado todavía; pero después de confirmar un cambio en Git, es muy difícil de perder, especialmente si se envía (push) la base de datos a otro repositorio con regularidad. Esto hace que usar Git sea un placer, porque se puede experimentar sin peligro de dañar gravemente lo hecho hasta ese momento. Git tiene tres estados principales en los que se pueden encontrar los archivos: confirmado (committed), modificado (modified), y preparado (staged). Confirmado significa que los datos están almacenados de manera segura en la base de datos local. Modificado, significa que se ha modificado el archivo pero todavía no se ha confirmado a la base de datos local. Y preparado, significa que se ha marcado un archivo modificado en su versión actual para que vaya en la próxima confirmación. Entonces un proyecto de Git cuenta con tres secciones principales: el directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area) lo cual se puede apreciar en la Figura 2.2(Chacon, 2009)..

(39) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 31. Figura.2.2. Directorio de trabajo, área de preparación, y directorio de Git.. En el directorio de Git es donde se almacenan los metadatos y la base de datos de objetos para el proyecto. Es la parte más importante de Git, y es lo que se copia cuando hay que clonar un repositorio desde otro ordenador. El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se coloca en disco de la máquina para que se pueda usar o modificar. El área de preparación es un sencillo archivo, generalmente contenido en el directorio de Git, que almacena información acerca de lo que va a ir en la próxima confirmación. En algunas ocasiones o algunos autores a ésta la denominan “índice”, pero cada vez es más frecuente referirse a ella como “área de preparación”. El flujo de trabajo básico del desarrollo en Git es:  Modificar una serie de archivos en el directorio de trabajo.  Preparar los archivos, añadiendo los instantes de ellos al área de preparación..

(40) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 32.  Confirmar los cambios, toma los archivos tal y como están en el área de preparación, y almacena ese instante de manera permanente en el directorio de Git. Una vez entendido esto, se tendrá un conocimiento básico de Git y teniendo instalado y configurado el mismo se puede comenzar a trabajar. Todo proyecto necesita un repositorio donde se guarden todos los cambios efectuados en el mismo. Por eso el primer paso es crear un repositorio. Se puede obtener de dos maneras: la primera se toma un proyecto o directorio existente y se importa en Git. La segunda se clona un repositorio Git existente desde otro servidor. Teniendo en cuenta que ya en el GARP se están desarrollando varios proyectos los cuales cuentan con sus respectivos repositorios, se utilizará en este trabajo la segunda forma creando primero un repositorio vacío. Mediante la herramienta Gerrit se crea un nuevo proyecto y éste a su vez crea un repositorio en Git. Una vez hecho esto, ya se contará con un repositorio el cual estará vacío. Los siguientes pasos serán ejecutados a través de comandos desde consola debido a que Git no cuenta con una interfaz. El primero de ellos es clonar el repositorio creado mediante el comando gitclone que se utiliza poniendo el mismo y a continuación la URL del proyecto que se creó en Gerrit y es el que se desea clonar como se muestra a continuación: $ git clone http://10.12.112.62/gerrit/arduplane Esto crea un directorio llamado "ArduPlane" en la máquina, el cual inicializa un directorio .git en su interior, descarga toda la información de ese repositorio, la cual no contará con archivos debido a que está vacío y se obtiene una copia de trabajo de la última versión. El siguiente paso será copiar en el repositorio clonado las carpetas que se seleccionaron anteriormente del software ArduPlane, hecho esto se habrá modificado el clon, luego se tratará que el repositorio de Git reconozca los cambios creados para poder agregar a éste los mismos..

(41) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 33. Para esto se necesitan hacer algunas operaciones, y confirmar el instante de esos cambios al repositorio. Debido a que cada archivo del directorio de trabajo puede estar en uno de estos dos estados: bajo seguimiento (tracked), o sin seguimiento (untracked). Los archivos bajo seguimiento son aquellos que existían en el último instante; pueden estar sin modificaciones, modificados, o preparados. Los archivos sin seguimiento son todos los demás, cualquier archivo del directorio que no estuviese en el último instante ni está en el área de preparación. La primera vez que se clona un repositorio, todos los archivos estarán bajo seguimiento y sin modificaciones, ya que se acaban de copiar y no han sido modificados. A medida que se editan archivos, Git los ve como modificados, porque se han cambiado desde la última confirmación. Se preparan estos archivos modificados y luego confirman todos los cambios que se hayan preparado, y el ciclo se repite. Este proceso queda ilustrado en la Figura 2.3.. Figura.2.3. El ciclo de vida del estado de los archivos. 2.3.1 Creación del repositorio en Git Se procede a ver el estado de los archivos del repositorio. Para determinar en qué estado se encuentran estos, se utiliza el comando git status. Si se ejecuta este comando justo después de clonar un repositorio, se podrá observar lo siguiente: $ git status # On branch master nothing to commit (working directory clean) Esto significa que se tiene un directorio de trabajo limpio, es decir, no contiene archivos bajo seguimiento y modificados. Git tampoco ve ningún archivo que no esté bajo seguimiento. Por último, este comando dice en qué rama está el proyecto. Al no haber especificado o.

(42) CAPÍTULO 2. IMPLEMENTACIÓN DEL SOFTWARE ARDUPLANE Y CONFIGURACIÓN DE LOS SERVIDORES. 34. creado otra rama siempre se encontrará en la "máster", que es la predeterminada. Entonces al añadirse nuevos archivos al proyecto tales como, ArduPlane libraries y mk, los que no existían antes al ejecutarse git status, se verán los archivos sin seguimiento como se muestra a continuación: $ vim Arduplane $ vim libraries $ vim mk $ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) ##ArduPlane nothing added to commit but untracked files present (use "git add" to track) ##libraries nothing added to commit but untracked files present (use "git add" to track) ##mk nothing added to commit but untracked files present (use "git add" to track) Ahora se pueden apreciar los nuevos archivos ArduPlane, libraries y mk que aparecen bajo la cabecera “Archivos sin seguimiento” (“Untracked files”) de la salida del comando. Sin seguimiento, significa básicamente que Git ve un archivo que no estaba en el instante anterior. Git no empezará a incluirlo en las confirmaciones del instante en que se encuentre hasta que se le indique explícitamente. Lo hace para que no se incluyan accidentalmente archivos binarios generados u otros archivos que no se tenía intención de incluir. Si se desea incluir estas tres carpetas, solo se debe iniciar el seguimiento de los archivos. Para empezar el seguimiento de un nuevo archivo se usa el comando git add. Por tanto se le dará seguimiento a los archivo ArduPlane, libraries y mk ejecutando el siguiente comando a cada carpeta por separado: $ git add ArduPlane $ git add libraries $ git add mk.