CLINKER. Ecosistema de Desarrollo Software

Transcripción

1 CLINKER Ecosistema de Desarrollo Software klicap - ingeniería del puzle, S.L. Parque Empresarial PISA C/Industria 1, Edificio Metropol 1, planta 3ª, módulo Mairena del Aljarafe Sevilla, España C.I.F. B hello@klicap.es Inscrita en el Registro Mercantil de Sevilla, Tomo 5192 Libro 0 Folio 175 Sección 8 Hoja SE Presentación de CLINKER Ecosistema de Desarrollo Software por klicap - ingeniería del puzle, S.L. se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

2 Índice de contenido 1 Introducción Modelo conceptual Características Arquitectura Detalles

3 1 Introducción Este documento es una presentación de CLINKER, un proyecto diseñado y construido por KLICAP INGENIERÍA DEL PUZLE, S.L. que nace a comienzos del año Para poder entender qué es y cuáles son sus objetivos es necesario conocer las distintas actividades que intervienen en el ciclo de vida del software. Para facilitar al lector la comprensión del presente documento, se va a proporcionar la siguiente definición: Un ecosistema de desarrollo software es un espacio de trabajo en el que conviven una serie de herramientas que acompañadas de unas buenas prácticas permiten a un equipo de desarrollo modelar una metodología de trabajo Esta es una de las múltiples definiciones que se pueden encontrar para definir este concepto. Concretamente esta definición fue elaborada por uno de los integrantes de KLICAP y publicada 1 en su blog personal el 9 de agosto de Este documento gira en torno a esta definición y es por ello, que no debe resultar extraño que a lo largo del documento se citen fragmentos de la misma. CLINKER es para su equipo un claro ejemplo de proyecto de integración. Desde el principio se coincidió en la idea de que ya existían herramientas que apoyaban en las múltiples actividades que se realizan en el complejo camino que conlleva desarrollar software. La mejor forma de garantizar esas integraciones era buscando herramientas que estuvieran pensadas para interoperar con otras o bien fueran libres y de fuente abierta. Y si fuera posible ambas cosas, más favorable aun la integración

4 2 Modelo conceptual En este bloque se presenta el modelo conceptual en el que está basada la implementación. Este modelo es simplemente una visión particular de KLICAP y que únicamente debe considerarse como línea base. A continuación se presentan los distintos componentes propuestos. Diagrama 1: Componentes que forman parte de un ecosistema de desarrollo software 2.1 Source Code Management También podemos referirnos como Software Configuration Management, en ambos casos se usa el acrónimo S.C.M. 2. Es quizás uno de los componentes clave del ecosistema, básicamente porque será donde persista el código de fuente, documentos, perfiles de configuración, etc. Precisamente su versatilidad es lo que hace que se pueda emplear para múltiples fines. Para este componente tenemos muchas opciones, que van desde la mítica herramienta CVS, hasta Git pasando por Subversion y Mercurial. En cualquier caso los objetivos más destacados de este componente es: 1. Contenedor de archivos 2. Histórico de cambios 3. Control de acceso 2.2 Instant Messaging Podemos encontrar este tipo de herramientas en soluciones HelpDesk, asistentes, redes sociales y en servicios destinados al ocio y el entretenimiento. Su finalidad parece evidente, poder intercambiar mensajes de texto con una o varias personas facilitando así un nuevo canal de comunicación. A diferencia de otras herramientas de comunicación, es bidireccional y aumenta el grado de participación e interacción. Puede jugar un papel muy importante dentro del ecosistema si por ejemplo además de poder intercambiar impresiones con otros miembros del equipo la usamos para recibir notificaciones (comunicación unidireccional) de eventos que surgen dentro del ecosistema. 2.3 Repository Manager Están muy relacionados con la herramientas de modelado y construcción de proyectos. Dentro de una 2 4

5 organización, división o departamento se crean y mantienen muchas líneas de código. Un pilar importante dentro de la ingeniería del software es la modularidad que conlleva consigo la reutilización de código. Cuando todo esto comienza a crecer se establecen dependencias que no pueden ser mantenibles de forma manual. Pues bien, para poner solución a este inconveniente y a otros que no se han descrito, existen herramientas que los solucionan proporcionando: 1. Administración de repositorios locales y externos 2. Información sobre las dependencias 3. Respaldo 4. Control de acceso 5. Búsquedas 6. Caché 2.4 Mailing List Manager Una herramienta muy común en cualquier entorno colaborativo que se precie. Permiten gestionar un conjunto de listas de correo, incluir moderación, procesos de suscripción, etc. Las listas de correo proporcionan un canal de comunicación bidireccional y pasivo, es decir la información fuye entre emisor y receptores en ambos sentidos y no se requiere que los receptores respondan en un tiempo determinado. A diferencia de la mensajería instantánea que sí requiere que existan receptores participando activamente. 2.5 Build Tool Sin lugar a dudas, constituyen el alma del ecosistema. Estas herramientas modelan nuestros proyectos de una forma reglada con independencia del modelado que ofrecen distintos IDEs. El modelado puede ir desde algo básico hasta propuestas más completas y sofisticadas. En este modelado podemos distinguir varias partes: 1. Datos básicos: nombre, descripción, licencia, clasificación, etc. 2. Versionado 3. Gestión de dependencias 4. Ciclo de vida del proceso de construcción 5. Definición de artefactos 3 Lo realmente importante y que no podemos dejar pasar por alto es que nuestros proyectos descritos y caracterizados con estas herramientas pueden ser entradas de otras herramientas que sepan manejarlos y manipularlos. 2.6 Project Management Son ese tipo de herramientas que según en qué contexto se traten pueden tener connotaciones distintas. Existen empresas que tienen soluciones para gestionar la dedicación de sus empleados a proyectos y otras incluyen este aspecto dentro del propio ecosistema. Dependiendo de si consideramos el esfuerzo o no, añadiremos una nueva dimensión a este tipo de herramienta. Ligado al esfuerzo está la estimación y como resultados de ambos, la desviación. Sobre estas herramientas se ha centralizado la mayor actividad dado que son el punto de referencia de los proyectos, aunque según el tipo de tarea que estemos realizando puede que no sea necesaria su intervención directa (p.e. haciendo un commit en el SCM). Son ese punto de entrada porque en ella recae la responsabilidad del seguimiento, organización y planificación

6 Los módulos más comunes en este tipo de herramientas son: 1. Wiki: herramienta que revolucionó la forma de generar documentación, publicar contenidos e interactuar de forma colaborativa 2. Roadmap: planificación detallada de hitos (entradas, releases, etc) 3. SCM Viewer: navegación por el código fuente, coloreado, búsquedas, históricos, etc. 4. Tickets: el ticket es un concepto muy general para modelar tareas que deben realizarse. Desde este módulo se proporciona una descripción, asignación y se realiza el seguimiento (trazabilidad) 5. Dashboard: vista resumida cubriendo funciones propias de los cuadros de mando 2.7 Continuous Integration & Build Se las puede considerar un planificador de tareas. Normalmente tienen como entradas: 1. Código fuente del proyecto modelado con una herramienta de construcción 2. Eventos que condicionan la ejecución de las tareas Son precisamente estos dos puntos los que nos permiten hablar de integración continua. Una forma de entenderlo es considerar como causa, cambios en 1 y 2, y como efecto, sus implicaciones (el resultado). También podemos hablar de sus salidas pero son tan amplias que se escapan del alcance de este documento. La automatización sería difícilmente alcanzable sin estas herramientas, sus beneficios son evidentes y necesarios. 2.8 Content Management System Es obvio que no todo lo que se genera en un proyecto es código fuente, y que no todo proyecto tiene por qué tener código fuente. Sólo tenemos que fijarnos en los proyectos de consultoría donde los objetivos quedan plasmados en documentos. La gestión documental es un concepto amplio y que en este contexto involucra a distintos módulos propuestos. Con el paso de tiempo se genera gran cantidad de información que debemos gestionar si queremos evitar una pérdida de conocimiento. Esta información (conocimiento) se puede encontrar en distintos formatos, podemos destacar documentos de texto tradicionales y formatos más ágiles como páginas wiki. Por lo tanto, es necesario: 1. Facilitar la recuperación de la información 2. Organización y clasificación 3. Auditoría y control de acceso 2.9 Source Code Quality Existen herramientas que analizan el código fuente y obtienen un conjunto de indicadores que nos proporcionan información sobre su estado. Además de estos indicadores se pueden obtener recomendaciones para actuar de forma preventiva ante errores potenciales. Digamos que estas herramientas ayudan a obtener una radiografía en un determinado momento del estado de salud de nuestros proyectos. Si relacionamos estas herramientas con la integración continua lo que se obtiene es una inspección continua que nos permite estudiar su evolución con respecto al tiempo. Siempre que nos refiramos a este componente lo estaremos haciendo desde su punto vista estático, es decir, dejando a un lado el comportamiento en ejecución (dinámico). 6

7 2.10 Single Sign On Siendo un modelo conceptual basado en la integración no podía ser otra forma, tenía que estar presente. Como se verá en secciones posteriores las distintas soluciones propuestas ya proporcionan sus propios mecanismos para gestionar usuarios, permisos, roles, etc. El objetivo de este componente es precisamente centralizar y delegar en un solo punto: 1. Almacén de credenciales (autenticación) 2. Administración de permisos, grupos y roles/perfiles (autorización) 3. Proporcionar un mecanismo para la integración de otras herramientas no contempladas 2.11 Backup Hoy en día existen soluciones de backup muy potentes y fexibles, y no es objetivo de este componente plantear alternativas sino complementar. La idea es poder realizar copias de seguridad con la información que gestiona nada herramienta y su configuración. De esta forma conseguiremos: 1. Facilitar la actualización de componentes. Tendremos copias de seguridad accesibles en caso de que algo falle. 2. Exportación de configuraciones en caso de necesitemos replicar en distintas instancias 3. Posibilidad de trasladar las copias de seguridad a otros soportes mediante ftp, rsync, ssh, etc Deployment Environment Un entorno de despliegue es un máquina -normalmente- virtualizada que proporciona un sistema operativo, librerías base, herramientas, servidores (web, bases de datos, ldap, etc.) y otras piezas de software para satisfacer requisitos no funcionales de nuestro proyecto. Estos entornos son realmente útiles para llevar a cabo buenas prácticas relacionadas con el aseguramiento de la calidad del software. En esta línea, klicap está trabajando en Clinker DE Library. Una colección de entornos que cubran escenarios comunes y estén disponibles de forma cómoda y sencilla. 7

8 3 Características En el apartado anterior se ha introducido un modelo conceptual sobre ecosistemas de desarrollo software. En la introducción se han descrito sus componentes dando una pincelada de las funcionalidades que aportan. En este apartado se mostrarán las características de la implementación que se ha llevado a cabo. Basado en soluciones maduras y consagradas Las herramientas propuestas son maduras, estables y poseen importantes comunidades. Esto asegura el mantenimiento y evolución de las mismas. Además están respaldadas por una gran colección de plugins, documentación, listas de distribución y foros. Solución flexible basada en la integración La implementación propuesta es sólo una línea base a modo de referencia. Su diseño ha sido concebido para que nuevas herramientas y sistemas de información puedan ser incorporados y se puedan interactuar con la información que gestionan. Las integraciones están basadas en estándares para mejorar la interoperabilidad. Un aliado en la externalización del desarrollo y factorías de software Define un espacio de trabajo colaborativo ideal para la externalización del desarrollo y las factorías de software. La definición de roles y permisos permite controlar qué funcionalidades están disponibles y la visibilidad de la información según el rol de cada participante. La actividad de los proyectos queda recogida en un único lugar, evitando islas de información. Ahorro en el mantenimiento de infraestructura a medida Podrás centrarte en el desarrollo de tu software en lugar de gastar tiempo y dinero en mantener tu propia solución a medida. Dejarás de preocuparte de actualizaciones, optimización y comprobar compatibilidades entre versiones. Sólo tendrás que estar pendiente de que el almacenamiento sea suficiente. Escalabilidad Desde la organización del sistema de ficheros hasta el aprovisionamiento de usuarios han sido pensados para que las tareas básicas de administración resulten cómodas y sencillas. El objetivo principal es que la incorporación de nuevos proyectos y participantes no suponga una carga en tareas propias de un administrador de sistemas, es más, ahora esta labor puede recaer en cualquier otro rol. Accesibilidad Sólo necesitarás una conexión a internet y un navegador web para poder acceder a toda la información que se gestiona en tu ecosistema. Todas tus herramientas disponibles a través de protocolos y puertos estándares. No intrusivo Si estás familiarizado con las herramientas propuestas perfecto, porque seguirás usándolas de la misma forma. Las integraciones que se han diseñado no modifican el modelo de datos propio de las herramientas, por lo que los plugins de terceros seguirán funcionando correctamente. 8

9 Un sólo login para acceder a todo La propuesta de Single Sign-On permite que los participantes hagan login una sola vez en cualquier de las herramientas y sus credenciales se propaguen entre el resto. Si ya dispones de un almacén de credenciales (LDAP, base de datos, SSO, etc) será muy sencillo usarlo como fuente de datos para el proceso de autenticación. Su gestión de identidades permite definir permisos al mismo nivel que lo permiten las herramientas propuestas y que sólo tengas que dar de alta a los participantes una sólo vez. 9

10 4 Arquitectura Diagrama 2: Componentes Con este diagrama se pone de manifiesto el estado actual de la implementación. Algunas notas importantes: 1. Se opta por MySQL como motor de base de datos para los componentes Redmine, Trac, Sonar y Clinker SSO Gateway 2. El tráfico de red entre los usuarios y las herramientas se realiza a través de puertos estándares (HTTP/S) 3. En el componente Clinker SSO Gateway queda delegada la responsabilidad de gestionar las autenticaciones y autorizaciones 4. Actualmente los componentes integrados en el SSO son Redmine, Subversion, Sonar y Jenkins

11 Diagrama 3: Piezas 11

12 5 Detalles El sistema operativo elegido es Debian Squeeze GNU/Linux con kernel amd64 y se ha instalado: Software Versión Licencia Instalación Apache Web Server Apache License v2 Paquetes Apache Tomcat Apache License v2 Binario MySQL Server MySQL License Policy 4 Paquetes OpenSSH Server 5.5 BSD License Paquetes NTPd Paquetes rsync GNU GPL Paquetes Nexus GNU Afferro General Public License Binario Sonar 2.13 GNU LGPL v3 Binario Jenkins MIT License Binario Alfresco (d3370) Binario Trac BSD License (modified) 5 Fuentes Redmine Fuentes Subversion Apache License v2 Fuentes Lambda Probe 1.7b GNU GPL v2 Binario Awstats 7.0 GNU GPL Binario JDK Binario Apache Maven Apache License v2 Binario Apache Maven Apache License v2 Binario PHP PHP License v Paquetes Python PSF License 7 Paquetes CMIS Trac Plugin GNU GPL v3 Fuentes Stractistics Trac Plugin GNU GPL v2 Fuentes Clinker SSO Gateway Comercial Fuentes Jenkins Auth Clinker Plugin Comercial Fuentes Sonar Auth Clinker Plugin Comercial Fuentes Redmine Auth Clinker Plugin Comercial Fuentes La máquina virtual se distribuye con la misma licencia que el presente documento, lo que implica: 1. Puedes copiar y distribuir la máquina virtual siempre y cuando quede clara su autoría 2. Puedes copiar y distribuir la máquina virtual siempre y cuando no existan fines comerciales 3. Puedes copiar y distribuir la máquina virtual sin realizar modificaciones