Diseño e implementación de un sistema de aprovisionamiento automático de herramientas DevOps para una organización dedicada al desarrollo de software

Texto completo

(1)DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE. PILAR STEPHANY MASS LÓPEZ. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA BOGOTÁ D.C. 2018.

(2) DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE.. PILAR STEPHANY MASS LÓPEZ. Trabajo de informe de monografía para optar el título de Ingeniera Telemática. Director NORBERTO NOVOA Coordinador Tec. Sistematización de Datos e Ingeniería Telemática Magister en Educación Informática. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA BOGOTÁ D.C. 2018.

(3) Nota de aceptación. _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________ _______________________________. Tutor _______________________________ Ing. Norberto Novoa. Jurado. ______________________________ Ing. Sonia Alexandra Pinzón. Bogotá D.C, Septiembre de 2018.

(4) INTRODUCCIÓN El presente documento describe y muestra las actividades correspondientes al desarrollo del proyecto: DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE, cuyo fin es el de permitir el acceso e integración a múltiples programas, herramientas y configuraciones que determinada empresa necesite para hacer el desarrollo sistemático de su producto final. El objetivo del proyecto descrito en este documento es el de permitir a una determinada empresa mejorar el proceso “End to End” del desarrollo de un software o producto, el cual, comprende las etapas de desarrollo, pruebas y puesta en producción; a partir de la implementación de un sistema web separado entre Back-End y Front-End, que mediante la utilización del patrón MVC orientado a Microservicios y con tecnologías tales como Java Spring Boot, Angular 6 en conjunto con Ionic 3 y REST API permitan la instalación y configuración automática de herramientas DevOps (herramientas de desarrollo y operaciones) en cada ambiente de trabajo de una empresa. Los ambientes de trabajo a considerar son: ambiente de desarrollo, el cual es el entorno en el cual el equipo de desarrollo puede ejecutar sus tareas sin preocuparse por dañar la última versión estable de un producto final; el ambiente de QA es el ambiente propicio en el cual, analistas pueden realizar pruebas unitarias y de integración sobre las entregas ejecutadas en el ambiente de desarrollo, por último, se encuentra el ambiente de producción, en el cual se aloja la versión estable del producto, generalmente aislado para evitar complicaciones de seguridad y/o disponibilidad, entre otros factores. La instalación y configuración automática se lleva a cabo en máquinas conectadas en redes locales para los ambientes de desarrollo y pruebas, para el caso de ambiente productivo el sistema aprovisionador se conectará a través de SSH a una instancia virtual en la nube. Además de las tecnologías mencionadas anteriormente para realizar el desarrollo del presente proyecto, como sistema de gestión de base de datos se utiliza PostgreSQL por ser un motor de base de datos con distribución libre y, además, su capacidad de gestionar bases de datos potentes y robustas, entre otras ventajas. La estructura del desarrollo del proyecto seguirá las fases de la metodología RUP, comenzando con la fase de planeación en donde la idea inicial constituye lo que se quiere crear, contiene el qué y el cómo. Con esta idea se identifican las necesidades, se reconoce el problema definiendo el propósito del aplicativo y se organiza un plan de actividades en donde se define el tiempo de desarrollo..

(5) La siguiente fase, fase de análisis, detallará los requerimientos del sistema, proseguida por la fase de análisis que busca modelar el producto final deseado, a través de diagramas UML. Posteriormente la fase de implementación, en esta fase se construye el software, se integran los elementos del sistema produciéndose las distintas pantallas, se crean y se enlazan los elementos correspondientes. Se materializa el borrador efectuado en la fase del diseño y por último se encuentran las pruebas tienen como finalidad de depurar (hacer correcciones y localizar fallos) del prototipo a partir de su utilización por un grupo de usuarios (colaboradores); estos usuarios serán capaces de señalar puntos débiles, que cosas les agradaría que tuviera el aplicativo y que cosas no, como es la experiencia del manejo del proyecto. El aprovisionamiento automático se realiza con la ayuda de la herramienta Ansible, Ansible es un programa de software libre que realiza instalaciones multi-hilo a través de archivos llamados Task, en donde se encuentra toda la orquestación de la operatividad de Ansible, es decir, todo el libreto que Ansible necesita para realizar instalaciones y configuraciones. Es conveniente aclarar que la plataforma funciona especialmente en sistemas operativos con distribución Linux, debido a que las ventajas de trabajar y operar en software libre son mayores comparadas con trabajar en otros S.O como Windows o IOS, con los cuales se debe pagar para obtener permisos de distribución y de fabricante..

(6) RESUMEN. Muchas empresas dedicadas al desarrollo de software tienen la necesidad de automatizar tareas como el aprovisionamiento y configuración de sus diferentes servidores o máquinas de trabajo, automatizar este tipo de tareas puede hacer que la productividad de los desarrolladores, analistas y personal de operaciones incremente sustancialmente. El presente trabajo de informe mostrará el proceso de desarrollo e implementación del sistema PROVISIONER para la creación y administración de ambientes de trabajo, comprendidos en: ambiente de desarrollo, ambiente de pruebas y ambiente de producción; siguiendo la metodología RUP, basándose en el patrón de arquitectura MVC y desarrollado en STS IDE bajo el lenguaje Java Spring Boot en el Back-End y Angular 6/Ionic 3 en el Front-End. Spring Boot permite desarrollar servicios HTTP, dando como resultado una serie de interfaces llamadas REST, que permiten obtener información en formato JSON, el cual es mucho más liviano comparado con el formato XML. En conjunto con el lenguaje java, el sistema PROVISIONER se desarrolló con Angular 6 en el proyecto Front-End, un framework de JavaScript que permite, precisamente, realizar peticiones HTTP sin dificultad alguna hacia el Back-End y, una vez realizada la petición evita sobrecargar con peticiones al servidor. El desarrollo del presente proyecto permite que cualquier empresa pueda realizar el aprovisionamiento de “x” cantidad de máquinas y/o servidores en cada ambiente de trabajo, sin tener que invertir horas de trabajo humano realizando estas tareas, lo que produce mayor productividad y reduce el tiempo ocioso en los integrantes de los equipos de trabajo, además de mantener integración continua en los proyectos de la empresa. El aprovisionamiento de los ambientes de desarrollo y pruebas se realiza en máquinas conectadas en redes de área local, para el ambiente productivo, el sistema se conecta a instancias EC2 Amazon en la nube que contiene el producto estable de la empresa y mantiene aislado al mismo. Los ambientes de trabajo ayudan a aumentar la organización de un proyecto, y reducir los riesgos debido a errores técnicos y humanos que puedan afectar de forma adversa a clientes y propios. Estos están organizados a tres capas: ambiente de desarrollo, ambiente de pruebas y, por último, ambiente de producción. Adicionalmente se utiliza como herramienta clave Ansible, un software libre que logra realizar instalación y configuración de software en múltiples terminales; cuyo funcionamiento se basa en archivos llamados Task con extensión YML, que contienen el paso a paso del qué y cómo realizar aprovisionamiento..

(7) ABSTRACT. Many companies dedicated to the development of software have the need to automate tasks such as the provisioning of their different servers or machines, automating this type of tasks can cause the productivity of the developers, analysts and maintenance personnel to increase substantially. This report will show the process of development and implementation of the PROVISIOINER system for the creation and administration of work environment environments, including: development environment, testing environment and production environment, following the RUP methodology, based on the MVC architecture pattern and developed in STS IDE under the Java Spring Boot language in the Back-End, which allows to develop HTTP services, resulting in a series of interfaces called REST, which allow obtaining information in JSON format, which is much lighter than the XML data format. In conjunction with the java language, the PROVISIONER system was developed with Angular 6 in the Front-End project, a JavaScript framework that allows, precisely, to make HTTP requests without any difficulty towards the Back-End and, once the request is made, it avoids performing new requests to the server. The development of this project allows any company to perform the supply of "x" number of machines and / or servers, without having to invest hours of human work performing these tasks, which produces greater productivity and reduce idle time in the members of work teams. The provisioning of the development and test environments is done in machines connected in local area networks, for the productive environment, the system connects to Amazon EC2 instances in the cloud that contains the stable product of the company and keeps it isolated. Work environments help reduce risks due to technical errors that can adversely affect customers and employees, and are organized into three layers: development environment, testing environment and, finally, production environment. Additionally, Ansible is a key tool, free software that manages installation and configuration of software in multiple terminals, whose operation is based on files called Task with YML extension, which contain the step-by-step of how and how to perform provisioning..

(8) CONTENIDO 2.. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN ................... 13 2.1.. TÍTULO .............................................................................................. 13. 2.2.. TEMA ................................................................................................. 13. 2.3.. PROBLEMÁTICA ............................................................................... 13. 2.4.. OBJETIVOS ....................................................................................... 14. 2.4.1. Objetivo general ................................................................................. 14 2.4.2. Objetivos específicos ......................................................................... 14 2.5.. DELIMITACIONES ............................................................................. 14. 2.6.. MARCO DE REFERENCIA ................................................................ 15. 2.6.1. Marco teórico ..................................................................................... 15 2.6.2. Marco histórico ................................................................................... 36 2.7.. ALCANCE .......................................................................................... 38. 2.8.. FACTIBILIDAD ................................................................................... 39. 2.8.1. Factibilidad Técnica ........................................................................... 39 2.8.2. Factibilidad Operativa ........................................................................ 39 2.8.3. Factibilidad Legal y Económica .......................................................... 40 2.9.. CRONOGRAMA................................................................................. 41. ......................................................................................................................... 41 3.. MODELO DEL NEGOCIO ........................................................................ 42 3.1.. Diagramas de procesos ..................................................................... 42. 3.1.1. Módulo de creación del ambiente de desarrollo ................................. 42 3.1.2. Modulo de creación de ambiente de pruebas .................................... 43 3.1.3. Módulo de creación de ambiente de producción ................................ 45. 4.. 3.2.. Modelo de dominio creación del ambiente de desarrollo ................... 46. 3.3.. Modelo de dominio de creación del entorno de pruebas.................... 46. 3.4.. Modelo de dominio de creación de ambiente de producción ............. 46. 3.5.. Modelo de dominio general ................................................................ 47. 3.6.. Glosario de Términos ......................................................................... 48. FASE DE REQUERIMIENTOS ................................................................. 50 REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES....................... 50 4.1.. Requerimientos Funcionales .............................................................. 50.

(9) 4.2. 5.. 6.. 7.. 8.. Requerimientos No Funcionales ........................................................ 50. FASE DE ANÁLISIS ................................................................................. 52 5.1.. Definición de actores.......................................................................... 52. 5.2.. Lista preliminar de los casos de uso .................................................. 52. 5.3.. Documentación casos de uso y diagramas de casos de uso ............. 54. 5.4.. Diagramas de secuencia .................................................................... 59. 5.5.. Diagramas de actividad ...................................................................... 62. 5.6.. Diagramas de colaboración ............................................................... 64. FASE DE DISEÑO .................................................................................... 66 6.1.. Lista inicial de clases ......................................................................... 66. 6.2.. Diagrama de clases ........................................................................... 66. 6.3.. Diagrama de Entidad – Relación ....................................................... 68. 6.4.. Diagrama de Interfaz.......................................................................... 68. 6.5.. Diccionario de datos........................................................................... 69. FASE DE IMPLEMENTACIÓN ................................................................. 72 7.1.. Arquitectura ........................................................................................ 72. 7.2.. Diagrama de componentes ................................................................ 73. 7.3.. Diagrama de despliegue .................................................................... 74. 7.4.. Diagrama de paquetes ....................................................................... 75. FASE DE PRUEBAS ................................................................................ 77 8.1.. Pruebas unitarias ............................................................................... 80. 8.2. Pruebas de Integración ...................................................................... 83 CONCLUSIONES ..................................................................................... 88 RECOMENDACIONES ............................................................................. 89 ANEXOS ................................................................................................... 90 BIBLIOGRAFÍA ....................................................................................... 134 INFOGRAFÍA………………………………………………………………… 135.

(10) Índice de Figuras Figura 1.Modelo entornos desarrollo, prueba y producción. ............................ 18 Figura 2.Infraestructura IaaS. ........................................................................... 30 Figura 3.Centros clientes AMAZON. ................................................................ 32 Figura 4.Muestra un ejemplo básico que se ejecuta en una arquitectura simplificada del sistema informático. ................................................................ 34 Figura 5.Ejecución Docker. .............................................................................. 34 Figura 6.Ansible le permite traducir este diagrama en un plano, que define las políticas de infraestructura. .............................................................................. 36 Figura 7. Diagrama de proceso modulo compañía ........................................... 43 Figura 8. Diagrama de proceso módulo proyecto............................................. 44 Figura 9. Diagrama de proceso módulo máquinas ........................................... 45 Figura 10. Diagrama de proceso módulo Tasks . ¡Error! Marcador no definido. Figura 11.Diagrama de dominio ambiente de desarrollo .................................. 46 Figura 12.Diagrama de dominio Módulo de creación del entorno de pruebas . 46 Figura 13.Diagrama de dominio Módulo de creación de ambiente de producción ......................................................................................................................... 47 Figura 14.Modelo de dominio del sistema ........................................................ 48 Figura 15.Diagrama caso de uso 3.1 ............................................................... 55 Figura 16.Diagrama de caso de uso 4.1 .......................................................... 56 Figura 17.Diagrama de caso de uso 5.1 .......................................................... 57 Figura 18.Diagrama de caso de uso 6 ............................................................. 59 Figura 19.Diagrama de Secuencia caso de Uso 3.1: Adición de proyecto con sus respectivos ambientes ............................................................................... 60 Figura 20.Diagrama de Secuencia caso de uso 4.1 Adicionar una máquina local ......................................................................................................................... 60 Figura 21.Crear Tasks Ansible (programas y configuraciones) para cada ambiente........................................................................................................... 61 Figura 22.El administrador de cada ambiente ejecuta el aprovisionamiento .... 61 Figura 23.Diagrama de actividad caso 3.1 ....................................................... 62 Figura 24.Diagrama de actividad caso 4.1 ....................................................... 62 Figura 25.Diagrama de actividad caso 5.1 ....................................................... 63 Figura 26.Diagrama de actividad caso 6.1 ....................................................... 63 Figura 27.Diagrama de colaboración caso 3.1 ................................................. 64 Figura 28.Diagrama de colaboración caso 4.1 ................................................. 64 Figura 29.Diagrama de colaboración caso 5.1 ................................................. 65 Figura 30.Diagrama de colaboración caso 6.1 ................................................. 65 Figura 31. Diagrama de clases......................................................................... 66 Figura 32.Diagrama E-R .................................................................................. 68 Figura 33.Diagrama de interfaz ........................................................................ 69 Figura 34. Diagrama de arquitectura ................................................................ 73 Figura 35.Diagrama de componentes .............................................................. 74 Figura 36.Diagrama de despliegue .................................................................. 75 Figura 37.Diagrama de paquetes ..................................................................... 76 Figura 38. Ejecutar aprovisionamiento Caso 6 ............................................... 133.

(11) Índice de tablas. Tabla 1.Presupuesto y fuentes de financiación. Elaboración Propia ................ 40 Tabla 2.Descripción de módulos principales .................................................... 42 Tabla 3.Glosario de Términos .......................................................................... 49 Tabla 4.Descripción de actores ........................................................................ 52 Tabla 5.Lista de casos de uso .......................................................................... 54 Tabla 6.Caso de Uso 3.1 Adición de proyecto con sus respectivos ambientes 54 Tabla 7.Caso de uso 4.1 .................................................................................. 56 Tabla 8.Caso de uso 5.1 .................................................................................. 57 Tabla 9.Caso de uso 6 ..................................................................................... 58 Tabla 10. Lista inicial de clases Back-End ....................................................... 66 Tabla 11.Lista inicial de clases Front-End ........................................................ 66 Tabla 12.Prueba unitaria 1 ............................................................................... 81 Tabla 13.Prueba unitaria 2 ............................................................................... 81 Tabla 14.Prueba unitaria 3 ............................................................................... 82 Tabla 15.Prueba unitaria 4 ............................................................................... 83 Tabla 16. Pruebas de integración 1 .................................................................. 84 Tabla 17.Pruebas de integración 2 ................................................................... 85 Tabla 18.Pruebas de integración 3 ................................................................... 85 Tabla 19.Pruebas de integración 4 ................................................................... 86.

(12) 1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN 1.1. TÍTULO DISEÑO E IMPLEMENTACION DE UN SISTEMA DE APROVISIONAMIENTO AUTOMATICO DE HERRAMIENTAS DEVOPS PARA UNA ORGANIZACIÓN DEDICADA AL DESARROLLO DE SOFTWARE 1.2. TEMA En el desarrollo del proyecto son abordados los temas de metodología de desarrollo de software (RUP), patrón de arquitectura MVC, servicios REST, cloud, aprovisionamiento, ambientes de trabajo, front-end, backend y ansible. 1.3. PROBLEMÁTICA Actualmente las empresas dedicadas a la creación de software deben tener ambientes de trabajo adecuados para los diferentes cargos que hay en el interior de ellas. Los programadores deben tener un ambiente de trabajo que cuente con el software necesario para poder desarrollar los requerimientos y hacer ajustes en el producto en el cual están trabajando; por otro lado, los tester o las personas encargadas en certificar la calidad del software deben tener acceso a los distintos desarrollos que van realizando los programadores a diario, esto con el fin de poder probar y encontrar inconsistencias en el producto, por último, el cliente debe tener a su disposición el sistema desarrollado, éste debe tener las siguientes características: usable, seguro, flexible, portable y tener el nivel de disponibilidad necesaria para todos los usuarios que lo usaran. Teniendo en cuenta que estos ambientes son creados y configurados de manera manual y que por lo general se presentan diversos problemas en la integridad y homogeneidad de los ambientes del mismo tipo, tales como: equipos de trabajo donde el producto no funciona, ambientes de QA que no son homogéneos a los ambientes de desarrollo y producción, ambientes de producción donde el producto instalado no contiene las versiones actualizadas de los desarrollos, el producto tiene inconsistencias no controladas e incluso cuando se realiza la adquisición de nuevos integrantes en la empresa existen demoras en tiempo para la configuración de su ambiente local. ¿Cómo apoyar la mejora de los procesos de generación y configuración de ambientes de trabajo dentro de una organización dedicada al desarrollo software?. 13.

(13) 1.4. OBJETIVOS 1.4.1.. Objetivo general Diseñar y desarrollar un sistema web que permita el aprovisionamiento automático de herramientas DevOps en una organización dedicada al desarrollo de software.. 1.4.2.. Objetivos específicos •. Diseñar y desarrollar un módulo que permita crear y parametrizar un ambiente de trabajo dinámico de desarrollo, a la medida de las necesidades de la empresa.. •. Diseñar y desarrollar un módulo que permita la creación automática de un entorno de pruebas de integración que permita la certificación de la calidad de los desarrollos de la empresa basándose en la NORMA ISO/IEC 29119.. •. Diseñar y desarrollar un módulo que permita crear un ambiente de producción ajustable a la demanda de los productos de la empresa utilizando instancias virtuales de AWS Amazon.. •. Realizar la documentación técnica y funcional correspondiente al presente proyecto, incluyendo también manuales técnicos y funcionales.. 1.5. DELIMITACIONES Delimitación Geográfica El sistema será desarrollado en la domiciliación del estudiante. Delimitación Temporal El sistema incluyendo la documentación y manuales de usuario se ha proyectado a un tiempo de (6) meses. Delimitación Temática El sistema abordará los siguientes temas: RUP Modelado de negocio Requisitos Análisis Diseño Implementación Pruebas 14.

(14) UML 2.0 Patrón de arquitectura de Software MVC 1.6. MARCO DE REFERENCIA El diseño e implementación de un sistema de aprovisionamiento automático de herramientas DevOps (herramientas de desarrollo y operaciones) para una organización dedicada al desarrollo de software nace de la necesidad que tienen las fábricas de software al momento de contratar personal nuevo o incluso iniciar un la elaboración de un producto nuevo, ya que, el proceso de instalación y configuración para que una maquina posea el software necesario con el cual, un desarrollador, un “tester” o empleado operativo pueda realizar su trabajo, puede llegar a ser muy largo y/o desgastante. El sistema de aprovisionamiento “Provisioner”, pretende automatizar tareas humanas de búsqueda, descarga, instalación, actualización y configuración de software y/o herramientas, con el fin reducir tiempos de ejecución de las anteriores tares previamente mencionadas logrando que la curva de aprendizaje de un equipo de trabajo incremente, y aumentar productividad en fábricas de software.. 1.6.1.. Marco teórico Ambientes de trabajo. El manejo de los ambientes de trabajo dentro de una organización se hizo imprescindible desde que se deseaba obtener un producto estable sin que pruebas o nuevos desarrollos realizados sobre el software afectan la funcionalidad de este. Fue así como se dio lugar a diferentes políticas y estándares que dan como resultado buenas prácticas dentro de un equipo de trabajo. “El modelo de desarrollo, testing y producción es esencial para proveer los controles y el balance necesario para ejecutar un entorno de producción de alta disponibilidad de forma eficiente.” El modelo de desarrollo, testing y producción. (2013). Recuperado de: https://www.linuxito.com/programacion/237-el-modelo-de-desarrollotesting-y-produccion. Las diferentes practicas comprenden: •. Analizar las características de cada ambiente, en el cual se incluyan limitantes, características necesarias, etc. 15.

(15) • •. •. •. • •. Podría residir en el computador personal del desarrollador, en otros casos, podría ser un servidor compartido en el cual varios desarrolladores trabajan sobre el mismo proyecto. Ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir situaciones en las cuales el software desarrollado presente comportamientos distintos y errores en esos ambientes. También en componentes de infraestructura de TI deben ser similares, por ejemplo, ¿usa clúster en producción?, si es así, ¿Cómo se asegura que los componentes instalados en un servidor puedan desplegarse hacia otros servidores que componen el clúster? La única forma, es tener un ambiente de desarrollo o pruebas configurado en clúster en el cual los desarrolladores puedan validar sus programas. “Incluir réplicas de todos los componentes con los cuales el software tendrá interoperación en producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales, componentes middleware, interfaces, demonios (Daemon), procesos personalizados, utilidades FTP y otros.” Utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a efectos de evitar confusión durante la ejecución de las pruebas. “Tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de una base de datos a otros.”. Norma de separación de Ambientes de trabajo Sistemas. (s,f). Recuperado de: https://www.hospitalitaliano.org.ar/multimedia/archivos/clases_attach s/1982-19.pdf. Herramientas DevOps DevOps es un acrónimo inglés de development (desarrollo) y operations (operaciones o sistemas); se refiere a una práctica de ingeniería de software que se centra en realizar la unificación entre el desarrollo de software (Dev) y la operación (Ops). La principal característica del movimiento DevOps es proveer enérgicamente la automatización y el monitoreo en todos los pasos de la construcción. 16.

(16) del software, desde la integración, las pruebas, la liberación hasta la implementación y la administración de la infraestructura.1. Ambientes de trabajo basados en el modelo desarrollo, testing, producción Un entorno es un espacio técnico de trabajo que posee un alcance bien definido y respetado. La principal ventaja de los entornos es que ayudan a reducir los riesgos debido a errores técnicos que puedan afectar de forma adversa a un grupo de personas mayor al absolutamente necesario. El modelo de desarrollo, pruebas y producción es esencial para un software final eficiente y que cumpla con las expectativas. Creación de aplicaciones a tres capas: Desarrollo: Es el entorno de trabajo para desarrolladores individuales o pequeños equipos de desarrolladores. Trabajando de forma aislada con el resto de los ambientes, para permitir a los desarrolladores realizar y probar cambios radicales en el código sin afectar de forma adversa al resto del equipo de trabajo. Estos entornos suelen estar ubicados localmente. Pruebas de integración QA: Es un entorno común donde todos los desarrolladores realizan la “subida” de los cambios en el código. La meta de este entorno es combinar y validar el trabajo del equipo completo del proyecto para que pueda ser testeado. La capa de pruebas es un entorno lo más idéntico posible al entorno de producción. El objetivo principal del entorno de QA es simular al entorno de producción con el fin de testear las actualizaciones (en un entorno similar al de producción) para asegurar que las mismas no corrompen la aplicación existente en los servidores en producción. De esta forma se minimizan los errores en producción, las demoras en entregas y las posibles marchas atrás a cambios indeseados. Producción: La capa de producción puede incluir un servidor único o un “clúster” de servidores, bien sea físicos o virtualizados en la nube.. 1. Somerville, I. (2011). Ingeniería de Software, p. 30. México: Editorial Pearson. 17.

(17) Es el entorno donde trabajan los usuarios finales y se trabaja con los datos reales de negocio.. Figura 1.Modelo entornos desarrollo, prueba y producción. Recuperado de www.programacion/237-el-modelo-de-desarrollo-testing-y-produccion.. Metodología de desarrollo RUP Concepto El Rational Unified Process (RUP) es un proceso de ingeniería de software, creado por Ivar Jacobson, Grady Booch y James Rumbaugh, podemos definir RUP como el proceso unificado de desarrollo cuyo principal objetivo es el de mejorar la productividad y el proceso de desarrollo de software de un equipo de trabajo, así como también dar como resultado la puesta en marcha de las mejores prácticas en el desarrollo de software por parte de los integrantes de dicho equipo. RUP y la arquitectura Según Marcela García Alonso de la Universidad Tecnológica de Izucar de Matamoros el RUP es un proceso centrado en la arquitectura. La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además, la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. 18.

(18) La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.2 Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software. Fases de trabajo en RUP • Modelado Del Negocio:. Etapa del proceso que ayuda a establecer las reglas dentro de las cuales se puede llevar a cabo la creación o puesta en marcha del proyecto, además nos ayuda a identificar las posibles restricciones que se tendrán en la ejecución del proyecto. Se establecen y se tienen claros los objetivos, la misión y visión del proyecto. • Requerimientos: En esta etapa se deben establecer las necesidades funcionales y no funcionales del sistema que se quiera desarrollar en el proyecto; identificar los requerimientos permite visualizar la funcionalidad y los insumos necesarios para que el proyecto se vuelva una realidad. Requerimientos funcionales:. 2. Rueda, J. (2006). Aplicación De La Metodología RUP Para El Desarrollo Rápido De Aplicaciones basado En El Estándar J2EE, p. 4. Guatemala.. 19.

(19) Se describen las operaciones y/o acciones que los futuros usuarios tengan que realizar al utilizar el sistema, y las operaciones que debe realizar el sistema para dar respuesta óptima al usuario. Requerimientos No Funcionales: Se enumeran los recursos necesarios para la Implementación del sistema (Software), como son el hardware y el software que no permitirán ejecutar el proyecto. • Análisis: Identificar y establecer las especificaciones técnicas del proyecto (Software), es decir identificar los requerimientos utilizando el leguaje de los desarrolladores para producir una proyección interna (Conceptual) del sistema. Buscar un puente entre el lenguaje que maneja el desarrollador y el lenguaje común para el usuario.3 En esta etapa se deben realizar las siguientes actividades: Realizar un diagrama de secuencia de cada caso de uso. Realizar los correspondientes diagramas de actividad. Realizar un diagrama de colaboración de cada caso de uso. Obtener un diagrama de estado de cada caso de uso general. • Diseño: Etapa en la cual se debe tener como resultado un modelo lógico del sistema a implementar, el cual debe ser físico y concreto. Es un plano de la implantación. El resultado del diseño debe ser mantenido durante todo el ciclo de vida del Software. Los pasos por seguir son los siguientes: ▪ Lo primero que se tiene que realizar es una lista inicial de objetos. ▪ Se debe retinar las responsabilidades de los objetos. ▪ Se deben identificar operaciones y atributos de los objetos, e interacciones entre Estos. ▪ Por último, se tiene que detallar las relaciones entre los objetos. • Implementación: Etapa en la que se deben codificar los resultados obtenidos en el diseñó en a nivel de componentes como archivos de código fuente, ejecutables, scripts, etc. Lo más lógico es que aquí se implementen. 3. Rueda, J. (2006). Aplicación De La Metodología RUP Para El Desarrollo Rápido De: Aplicaciones basado En El Estándar J2EE, p. 6. Guatemala: Grijalbo. 20.

(20) las clases encontradas durante el diseño convirtiéndolas, si es necesario, en código. Otro de los objetivos de la implementación radica en probar los componentes individualmente e integrarlos en uno o más ejecutables. Los pasos por seguir son: ▪ ▪ ▪. Realizar pruebas de unidad (componentes individuales) Unificar componentes de acuerdo con el diagrama de componentes, en donde se establece como se organizan los componentes y dependen unos de otros. Identificar componentes e incorporarlos al modelo general.. • Pruebas: En esta etapa se prueba la estructura en general del sistema implementado y cada uno de los componentes o subsistemas que la conforman. Las pruebas se pueden realizar en diferentes casos y se deben realizar de acuerdo con el siguiente orden: Ejecutar las pruebas, comparar los resultados de las pruebas con los resultados esperados y ver las diferencias. Analizar los componentes y las pruebas diseñadas que presentaron esas discrepancias para un posible rediseño del componente o cambios en la prueba. Pueden realizarse pruebas de dos tipos: de integración y de aceptación. Pruebas de Integración: Las pruebas de integración buscan probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto.4 Pruebas de sistema: Pruebas que buscan garantizar que el desarrollo cumpla con los objetivos planteados inicialmente. Iteraciones: Se realizan cada una de las etapas correspondientes a la metodología, durante 4 iteraciones, las cuales son: iniciación, elaboración, construcción, y transición.. 4. Pruebas de integración, la hora de la verdad para el software. (2017). Recuperado de: https://www.obs-edu.com/int/blog-investigacion/sistemas/pruebas-de-integracion-la-hora-dela-verdad-para-el-software. 21.

(21) Iniciación: En esta iteración encontramos la primera fase de un proyecto y en gran parte se encuentran asociadas actividades de la fase de modelado de negocio. Elaboración: En esta iteración podemos encontrar las actividades relacionadas en mayor volumen a la fase de requerimientos Construcción: En esta iteración encontramos en su gran mayoría actividades de la fase de implementación. Transición: En esta iteración encontramos las actividades relacionadas a la fase final de RUP denominada despliegue. Según Departamento de Sistemas Informáticos y Computación de la Universidad Politécnica de Valencia: Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía. Cabe anotar que las actividades de cada fase son independientes de las iteraciones, lo cual a su vez permite identificar de una manera eficiente que operaciones se están realizando en tiempos que no corresponden para establecer correcciones sobre un proyecto.5 NORMA DE PRUEBAS ISO/IEC/IEEE 29119. Esta norma surge como la necesidad de estandarizar pruebas a nivel mundial, pues no existía claridad a la hora de realizar testing. Esta norma define el vocabulario, procesos, documentación, técnicas y un modelo de evaluación del proceso de pruebas de software que se puede utilizar dentro de cualquier ciclo de vida de desarrollo. Servirá para guiar la tendencia que existe en torno a la mejora de las pruebas del software, permitiendo normalizar el modo en que se planifican, diseñan, ejecutan y mantienen las pruebas, así como la manera en que se gestiona dentro de una organización el conocido, pero normalmente olvidado, proceso de Testing.6. 5. 6. Introducción a RUP, (s, f). Universidad Politécnica de Valencia. Recuperado de: https://pid.disc.upv.es/C1/Material/Documentos%Documentos&2Disponibles/Introducción%2 0a/.doc Jimenez B. NORMA ISO 29119 PRUEBAS/TESTING, p.3. (2012). Santa Cruz: Grijalbo.. 22.

(22) ISO / IEC 29119 consta de las siguientes partes principalmente: Parte 1 Definiciones y Vocabulario Su objetivo es dar una visión general de la norma y de los conceptos generales de pruebas de software y proporcionar un vocabulario de términos de pruebas de software que cubren las pruebas de todo el ciclo de vida del software. Parte 2 Proceso de Pruebas La norma define un modelo de prueba de proceso genérico que se puede utilizar dentro de cualquier desarrollo de software y ciclo de vida de la prueba. Este proceso se basa en un proceso de prueba de cuatro capas de cobertura: Especificaciones de organización de prueba (política organizativa de prueba, prueba de Estrategia Organizacional) Gestión de pruebas (prueba de gestión de proyectos, gestión de la fase de prueba) Los procesos dinámicos de prueba, incluyendo el diseño e implementación de prueba, entorno de prueba puesta a punto y mantenimiento, ejecución de pruebas y notificación de incidentes. Parte 3 Documentación de Pruebas El estándar cubrirá documentación de pruebas en todo el ciclo de vida completo del software de prueba. Esto incluye plantillas que se pueden personalizar y que cubra todas las fases del proceso de pruebas. Parte 4 Técnicas de Pruebas Descripción de las técnicas aplicadas. Java Spring Boot Para comenzar con la definición de Java Spring Boot es necesario remontarse a Spring, un framework muy popular en los últimos años que permite realizar aplicaciones empresariales, compuesto de herramientas que optimizan el rendimiento de cualquier aplicación, pues, utiliza la inyección de dependencias como filosofía principal, de esta manera, “la inyección de dependencias nos permite solucionar de forma sencilla y elegante cómo proporcionar a un objeto cliente acceso a un objeto que da un servicio que este necesita”. Introducción a Spring, p.5. (2012). Recuperado de: http://www.jtech.ua.es/j2ee/publico/spring-2012-13/wholesite.pdf Angular Angular es un framework de desarrollo para JavaScript creado por Google. La finalidad de Angular es facilitarnos el desarrollo de aplicaciones web SPA, es decir, una sola página, en la cual la navegación entre secciones y páginas de la aplicación, así como la carga de datos, se realiza de manera dinámica, casi instantánea, 23.

(23) asíncronamente haciendo llamadas al servidor (Back-End con un API REST) y sobre todo sin refrescar la página en ningún momento.7 Actualmente está disponible la versión 6, la cual tiene como particularidades que todas las respuestas del Back-End vienen por defecto en formato JSON, sin tener que utilizar funciones adicionales para realizar conversiones de datos. JSON JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje, pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.8 REST API Una API REST es una interfaz de programación de aplicaciones que utiliza solicitudes HTTP para obtener datos de solicitudes GET, PUT, POST y DELETE. Cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla.9 Una API REST, también conocida como RESTful web service, se basa en la tecnología de transferencia de estado representacional (REST), un estilo arquitectónico y un enfoque de las comunicaciones que a menudo se utilizan en el desarrollo de servicios web. Grandes empresas como Twitter, YouTube y los sistemas de identificación con Facebook utilizan REST al ser una solución más sencilla y más flexible que los servicios SOAP. Microservicios. 7. 8 9. Robles, V. (Diciembre 2017), ¿Qué es angular y para qué sirve? Recuperado de: https://victorroblesweb.es/2017/08/05/que-es-angular-y-para-que-sirve/ Introducción a JSON, (s, f). Recuperado de: https://www.json.org/json-es.html API REST: qué es y cuáles son sus ventajas en el desarrollo de proyectos. (Marzo 2016). Recuperado de: https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-susventajas-en-el-desarrollo-de-proyectos. 24.

(24) Una arquitectura de microservicios se compone de una colección de servicios autónomos y pequeños. Cada servicio es independiente el uno del otro y cada uno debe implementar una funcionalidad de negocio individual. “Estas son algunas de las características que definen un microservicio: • En una arquitectura de microservicios, los servicios son pequeños e independientes y están acoplados de forma flexible. • Cada servicio es un código base independiente, que puede administrarse por un equipo de desarrollo pequeño. • Los servicios pueden implementarse de manera independiente. Un equipo puede actualizar un servicio existente sin tener que volver a generar e implementar toda la aplicación. • Los servicios son los responsables de conservar sus propios datos o estado externo. Esto difiere del modelo tradicional, donde una capa de datos independiente controla la persistencia de los datos. • Los servicios se comunican entre sí mediante API bien definidas. Los detalles de la implementación interna de cada servicio se ocultan frente a otros servicios. • No es necesario que los servicios compartan la misma pila de tecnología, las bibliotecas o los marcos de trabajo.” Wasson, M. (2017). Estilo de arquitectura microservicios. Recuperado de: https://docs.microsoft.com/eses/azure/architecture/guide/architecture-styles/microservices IONIC 3 Ionic es una herramienta, gratuita y open source, para el desarrollo de aplicaciones híbridas basadas en HTML5, CSS y JS. Está construido con Sass y optimizado con Angular. Ionic está construido para ser rápido gracias a la mínima manipulación del DOM, con cero jQuery y con aceleraciones de transiciones por hardware. Ionic utiliza Angular con el fin de crear un marco más adecuado para desarrollar aplicaciones ricas y robustas. Ionic no sólo se ve bien, sino que su arquitectura central es robusta y seria para el desarrollo de aplicaciones. Trabaja perfectamente con Angular.10. 10. Pérez, J, J. (2015). Qué es y cómo empezar con Ionic Framework. Recuperado de: http://www.phonegapspain.com/que-es-y-como-empezar-con-ionic-framework/. 25.

(25) UML: Unified Modeler Language Permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de la industria, para comprender qué es el UML, podemos analizar cada una de las palabras que lo componen, por separado. •. Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación. •. Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste. •. Unificado: unifica varias técnicas de modelado en una única.. Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto modelado orientado a objetos, La principal diferencia de UML 2.0 con sus versiones anteriores se enfoca en estos dos objetivos: 1. Hacer el lenguaje de modelado mucho más extensible de lo que era. 2. Permitir la validación y ejecución de modelos creados mediante el UML. En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta percepción cambió de manera drástica y se modificó el lenguaje, de manera que permitiera capturar mucho más comportamiento. De esta forma, se permitió la creación de herramientas que soporten la automatización y generación de código ejecutable, a partir de modelos UML.11. PostgrestSQL PostgreSQL es un motor de base de datos más avanzado y popular en el manejo de bases de datos relacionales open-source se refiere,. 11. Rumbough J. Jacobson I. Booch, J. (2000). El lenguaje unificado de modelado. Manual de referencia, p. 7. Editorial Parsons. 26.

(26) además de ser gratuito y libre, ofrece una gran cantidad de opciones avanzadas. Una de las características de PostgreSQL es el control de concurrencias multisesión; o MVCC por sus siglas en inglés, lo cual nos permite hacer transacciones eventualmente consistentes, ofreciéndonos grandes ventajas en el rendimiento. En Postgres no se requiere usar bloqueos de lectura al realizar una transacción lo que nos brinda una mayor escalabilidad. También PostgreSQL tiene Hot-Standby. Este permite que los clientes hagan búsquedas (sólo de lectura) en los servidores mientras están en modo de recuperación o espera. Así podemos hacer tareas de mantenimiento o recuperación sin bloquear completamente el sistema.12 SSH SSH o Secure Shell, es un protocolo de administración remota que permite controlar y modificar servidores remotos a través de Internet. Proporciona varios mecanismos de autenticación través de diferentes técnicas de cifrado como lo es la encriptación simétrica, el cual utiliza una clave secreta tanto para el cifrado como para el descifrado de un mensaje tanto por el cliente como por el host. Esta clave es conocida como llave que cumplen la función de cifrar la información entre un cliente y un servidor. Integración continua La integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas. Los objetivos clave de la integración continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones de software.13 Con la integración continua, los desarrolladores envían los cambios de forma periódica a un repositorio compartido con un sistema de. 12. 13. Dontares, C, A. (2015). Qué es Postgres y cuáles son sus ventajas. Recuperado de: https://platzi.com/blog/que-es-postgresql/ Integración Continua ¿Qué, Cuando y Como? (noviembre 2016). Recuperado de https://otroespacioblog.wordpress.com/2016/11/17/integracion-continua-entrega-continuay-despliegue-continuo-que-cuando-y-como/. 27.

(27) control de versiones como Git. Antes de cada envío, los desarrolladores pueden elegir ejecutar pruebas de unidad local en el código como medida de verificación adicional antes de la integración. El servicio de integración continua detecta los envíos al repositorio compartido y crea y ejecuta de forma automática pruebas de unidad en los cambios en el código para detectar al instante cualquier error funcional o de integración.14 Entrega continua Con la entrega continua, se crean, prueban y preparan automáticamente los cambios en el código y se entregan para la fase de producción. La entrega continua amplía la integración continua al implementar todos los cambios en el código en un entorno de pruebas y/o de producción después de la fase de creación. Despliegue continuo El Despliegue Continuo es la implementación del patrón clásico Fail Fast (Fallar Rápido) para un proceso de entrega de software. Mientras más cerca ocurra un error del punto en el que fue introducido, más datos vamos a tener para corregir dicho error. En el código, Fail Fast significa que se debe lanzar una excepción ni bien detectamos parámetros o entradas incorrectas, en vez de esperar a que algo se rompa más adelante. En un proceso de entrega de software, Fail Fast significa entregar código a producción lo más rápido posible, en vez de esperar a todo un ciclo semanal o mensual (¡o más!) para que algo se rompa. El Despliegue Continuo es muy simple: hay que entregar el código a los clientes lo más rápido que podamos. Quizás hoy signifique hacerlo semanalmente en vez de mensualmente, pero con el tiempo vamos a poder acercarnos al ideal, e iremos viendo los beneficios en todo este proceso.15 Infraestructura como servicio (IaaS) y Hardware como servicio Las soluciones de infraestructura y hardware como servicio (IaaS / HaaS) son el segmento de mercado más popular y desarrollado de la computación en la nube. Proporcionan infraestructura. 14. 15. Amazon Web Services (AWS). ¿Qué es la integración continua?,(s, f). Recuperado de “https://aws.amazon.com/es/devops/continuous-integration/” Timothy, F. (2009). Continuos Deployment. Recuperado de “http://timothyfitz.com/2009/02/08/continuous-deployment/”. 28.

(28) personalizable a pedido. Las opciones disponibles dentro de IaaS ofrecen un rango de paraguas desde servidores individuales hasta infraestructuras enteras, incluidos dispositivos de red, balanceadores de carga y servidores de bases de datos y Web. La principal tecnología utilizada para entregar e implementar estas soluciones es la virtualización de hardware: una o más máquinas virtuales configuradas e interconectadas oportunamente definen el sistema distribuido sobre el cual se instalan y despliegan las aplicaciones. Las máquinas virtuales también constituyen los componentes atómicos que se implementan y tasan de acuerdo con las características específicas del hardware virtual: memoria, cantidad de procesadores y almacenamiento en disco. Las soluciones IaaS / HaaS ofrecen todos los beneficios de la virtualización de hardware: partición de la carga de trabajo, aislamiento de aplicaciones, sandboxing y ajuste de hardware. Desde la perspectiva del proveedor de servicios, IaaS / HaaS permite explotar mejor la infraestructura de TI y proporciona un entorno más seguro donde ejecutar aplicaciones de terceros. 16 Desde la perspectiva del cliente, reduce los costos de administración y mantenimiento, así como los costos de capital asignados para comprar hardware. Al mismo tiempo, los usuarios pueden aprovechar la personalización completa que ofrece la virtualización para desplegar su infraestructura en la nube; en la mayoría de los casos, las máquinas virtuales vienen con solo el sistema operativo seleccionado instalado y el sistema se puede configurar con todos los paquetes y aplicaciones requeridos. Otras soluciones proporcionan imágenes del sistema que ya contienen la pila de software requerida para los usos más comunes: Web servidores, servidores de bases de datos o LÁMP. Además de la gestión básica de la máquina virtual se pueden proporcionar servicios adicionales, generalmente incluyendo lo siguiente: basado en recursos del SLA asignación, gestión de carga de trabajo, soporte para diseño de infraestructura a través de interfaces web avanzadas, caras y la capacidad de integrar soluciones de IaaS de terceros. 17. 16. 17. Duarte, E. (Julio 2017). Cerrando la brecha de la discapacidad tecnológica. Recuperado de: http://blog.capacityacademy.com/2017/07/07/cerrando-la-brecha-de-la-discapacidadtecnologica-rafael-gerardo-tedxsantodomingo/ Rajkumar B, Christian V, Thamarai S. (2013). Kaufmann, p. 114. Mastering Cloud Computing.. Morgan. 29.

(29) Figura 2.Infraestructura IaaS. Recuperado de: https://garatucloud.com/beneficioscloud-gestionado-para-empresas/iaas-gestionado-infraestructura-como-servicio/. Computación en la nube Casi todas las soluciones de TI están etiquetadas con el término computación en la nube o simplemente en la nube hoy en día. Una palabra de moda puede ayudar a vender, pero es difícil trabajar en un libro. La computación en la nube, o la nube, es una metáfora para el suministro y el consumo de recursos de TI. Los recursos de TI en la nube no son visibles directamente para el usuario; hay capas de abstracción en el medio. El nivel de abstracción ofrecido por la nube puede variar de hardware virtual a sistemas distribuidos complejos.18 Los recursos están disponibles bajo demanda en cantidades enormes y se pagan uso. Las nubes a menudo se dividen en los siguientes tipos: Público: Una nube administrada por una organización y abierta al uso por el público en general. Privado: una nube que virtualiza y comparte la infraestructura de TI dentro de una sola organización.. 18. Computación en la nube, (s.f). Recuperado de http://www.mintic.gov.co/portal/604/w3propertyvalue-34317.html. 30.

(30) Híbrido: una mezcla de una nube pública y una privada. AWS es una nube pública. Los servicios de computación en la nube también tienen varias clasificaciones: Infraestructura como servicio (IaaS): ofrece recursos fundamentales como la informática, el almacenamiento y las capacidades de red, utilizando servidores virtuales como Amazon EC2, Google Compute Engine y máquinas virtuales de Microsoft Azure. Plataforma como servicio (PaaS): proporciona plataformas para desplegar aplicaciones personalizadas en la nube, como AWS Elastic Beanstalk, Google App Engine y Heroku. Software como servicio (SaaS): combina la infraestructura y el software que se ejecutan en la nube, incluidas aplicaciones de oficina como Amazon WorkSpaces, Google Apps for Work y Microsoft Office 365.19 Amazon web services (AWS) Amazon Web Services (AWS) es una plataforma de servicios web que ofrece soluciones para computación, almacenamiento y redes, en diferentes niveles de abstracción. Puede usar estos servicios para alojar sitios web, ejecutar aplicaciones empresariales y extraer enormes cantidades de datos. El término servicio web significa que los servicios se pueden controlar a través de una interfaz web. La interfaz web puede ser utilizada por máquinas o por humanos a través de una interfaz gráfica de usuario. Los servicios más destacados son EC2, que ofrece servidores virtuales y S3, que ofrece capacidad de almacenamiento. Los servicios en AWS funcionan bien juntos; puede usarlos para replicar la configuración local existente o diseñar una nueva configuración desde cero. Los servicios se cobran en un modelo de precios de pago por uso.20 La siguiente imagen muestra los centros de datos disponibles para todos los clientes:. 19 20. Andreas, M (2016). Amazon web services in action, p. 4 Manning Andreas, M (2016). Amazon web services in action, p. 3 Manning. 31.

(31) Figura 3.Centros clientes AMAZON, Recuperado de: https://services.amazon.es/servicios/amazon-ventas-globales/informacion-general.html. Software enfocado a orquestación de ambientes de desarrollo, QA y producción de forma distribuida Docker Docker es un programa de línea de comandos, un Daemon de fondo y un conjunto de servicios remotos que toman un enfoque logístico para resolver problemas de software comunes y simplificar su experiencia de instalación, ejecución, publicación y eliminación de software. Logra esto utilizando una tecnología UNIX llamada contenedores.21 Contenedores Históricamente, los sistemas operativos de estilo UNIX han utilizado el término “jail” para describir un entorno de ejecución modificado para un programa que evita que el programa acceda a recursos protegidos. Desde 2005, tras el lanzamiento de Solaris 10 y Solaris Containers de Sun, el contenedor se ha convertido en el término preferido para este entorno de tiempo de ejecución. El objetivo se ha ampliado de impedir el acceso a los recursos protegidos para aislar un proceso de todos los recursos excepto cuando se permita explícitamente. El uso de contenedores ha sido una buena práctica durante mucho tiempo. Sin embargo, la construcción manual de contenedores puede ser difícil y fácil de hacer incorrectamente. Este desafío los ha puesto fuera de alcance para algunos, y contenedores mal. 21. Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición.. 32.

(32) configurados han embrollado a otros en una falsa sensación de seguridad. Necesitamos una solución a este problema, y Docker ayuda. Cualquier software ejecutado con Docker se ejecuta dentro de un contenedor. Docker utiliza motores de contenedores existentes para proporcionar contenedores consistentes construidos de acuerdo con las mejores prácticas. Esto pone una mayor seguridad al alcance de todos. Con Docker, los usuarios obtienen contenedores a un costo mucho menor. A medida que Docker y sus motores de contenedores mejoran, obtendrá las últimas y mayores características de la cárcel. En lugar de mantenerse al día con el rápido desarrollo y el mundo altamente técnico de la construcción de cárceles de aplicación fuerte, puede dejar Docker manejar la mayor parte de eso para usted. Esto le ahorrará mucho tiempo y dinero y traerá la paz de la mente. 22 Los contenedores no son virtualización Sin Docker, las empresas normalmente utilizan la virtualización de hardware (también conocida como máquinas virtuales) para proporcionar aislamiento. Las máquinas virtuales proporcionan hardware virtual en el que se puede instalar un sistema operativo y otros programas. Tienen un tiempo largo (a menudo minutos) para crear y requieren gastos indirectos significativos del recurso porque ejecutan una copia entera de un sistema operativo además del software que usted desea utilizar. A diferencia de las máquinas virtuales, los contenedores Docker no utilizan virtualización de hardware. Los programas que se ejecutan dentro de los contenedores de Docker interactúan directamente con el kernel Linux del host. Debido a que no hay capa adicional entre el programa que se ejecuta dentro del contenedor y el sistema operativo de la computadora, no se desperdician recursos ejecutando software redundante o simulando hardware virtual. Esta es una distinción importante. Docker no es una tecnología de virtualización. En su lugar, le ayuda a utilizar la tecnología de contenedor ya incorporada en su sistema operativo.23 Ejecución de software en contenedores para aislamiento Como se señaló anteriormente, los contenedores han existido durante décadas. Docker utiliza los namespaces y cgroups de Linux, que han sido parte de Linux desde 2007. Docker no proporciona la tecnología de contenedores, pero específicamente hace que sea. 22 23. Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición. Nickoloff, J. (2016). Docker in action, p. 4. Manning Segunda Edición.. 33.

(33) más fácil de usar. Para entender cómo se ven los contenedores en un sistema, establezcamos primero una línea de base con la siguiente figura:. Figura 4.Muestra un ejemplo básico que se ejecuta en una arquitectura simplificada del sistema informático. Recuperado de: https://www.redhat.com/es/topics/containers/what-isdocker. Observe que la interfaz de línea de comandos, o CLI, se ejecuta en lo que se llama memoria de espacio de usuario al igual que otros programas que se ejecutan en la parte superior del sistema operativo. Idealmente los programas que se ejecutan en el espacio del usuario no pueden modificar la memoria del espacio del kernel. En términos generales, el sistema operativo es la interfaz entre todos los programas de usuario y el hardware en el que se está ejecutando el equipo. En la siguiente figura se puede ver que ejecutar Docker significa ejecutar dos programas en el espacio de usuario. El primero es el Daemon Docker. Si se instala correctamente, este proceso siempre debe estar en ejecución. El segundo es el Docker CLI. Este es el programa Docker con el que los usuarios interactúan. Si desea iniciar, detener o instalar software, emitirá un comando utilizando el programa Docker.. Figura 5.Ejecución Docker. Recuperado de https://www.redhat.com/es/topics/containers/what-is-docker. Muestra tres contenedores en ejecución. Cada uno se ejecuta como un proceso secundario del Daemon Docker, envuelto con un 34.

(34) contenedor y el proceso de delegado se ejecuta en su propio subespacio de memoria del espacio de usuario. Los programas que se ejecutan dentro de un contenedor pueden tener acceso sólo a su propia memoria y recursos según el alcance del contenedor.24. Software enfocado al aprovisionamiento y configuración de máquinas virtuales Ansible Ansible es una herramienta sencilla, flexible y extremadamente potente que le permite automatizar tareas comunes de infraestructura, ejecutar comandos e implementar aplicaciones multitecho que abarcan varias máquinas. A pesar de que puede utilizar Ansible para ejecutar comandos en varios hosts en paralelo, la verdadera potencia radica en administrar aquellos que usan playbooks. Como ingenieros de sistemas, la infraestructura que normalmente necesitamos automatizar contiene aplicaciones multitier complejas. Cada uno de los cuales representa una clase de servidores, por ejemplo, equilibradores de carga, servidores web, servidores de bases de datos, aplicaciones de almacenamiento en caché y colas de middleware. Dado que muchas de estas aplicaciones tienen que trabajar en tándem para proporcionar un servicio, también hay topología implicada. Por ejemplo, un equilibrador de carga se conecta a los servidores web, que a su vez leen / escriben en una base de datos y se conectan al servidor de almacenamiento en caché para recuperar objetos en memoria. La mayoría de las veces, cuando lanzamos dichas pilas de aplicaciones, necesitamos configurar estos componentes en un orden muy específico.. 24. Nickoloff, J. (2016). Docker in action, p. 5. Manning Segunda Edición.. 35.

(35) Figura 6.Ansible le permite traducir este diagrama en un plano, que define las políticas de infraestructura. Recuperado de https://www.ansible.com/resources/whitepapers/devops-and-legacy. 1.6.2.. Marco histórico. Historia de los entornos de los entornos de desarrollo integrados. Enero 1, 1952 El primer compilador fue escrito por Grace Hopper para el lenguaje de programacion A-0. Un compilador es un programa que se encarga de pasar el codigo fuente a lenguaje de bajo nivel capaz de ser interretado por una máquina. Posteriormente, Grace Hopper acuñó el término BUG. De ahí nace el termino Debugger o Depurador que es un ejecutable o una herramienta para probar y eliminar errores. Enero 1, 1975 El primer entorno integrado para desarrolladores se llamó Maestro que es un producto de Softlab Munich y fue el primero en el mundo del software. Enero 1, 1980 Las interfaces graficas se popularizan y como consecuencia se obtienen las GUI. La Interfaz Gráfica de Usuario (GUI) es el conjunto de elementos gráficos como ventanas, iconos, botones, etc.; que permiten una interacción Usuario-Aplicación. Algunos IDEs tienen incorporada esta herramienta para un buen desarrollo de software. Enero 1, 1984 VisualAge era el nombre de una familia de entorno integrado de desarrollo el cual manejaba múltiples lenguajes de programacion como: BASIC, COBOL, C, C + +, EGL, Fortran, Java, PACBASE, 36.

(36) Smalltalk y era multiplataforma. Con la salida al público del JDK desarrollado por SunMycrosystem, los IDE’s dieron un nuevo giro en cuanto a IDES más intuitivos y amables con el desarrollador, como por ejemplo Netbeans en Jan 1, 1997 totalmente escrito en Java. Por otro lado, en May 1, 1997 nace Visual Studio, un entorno diseñado para Sistemas Operativos Windows. Finalmente, en enero de 2001 nace el popular Eclipse, un reemplazo de VisualAge. Este Entorno Integrado de Desarrollo es de código abierto, los lenguajes de programacion que acepta son: JAVA, C, C++, JSP, PHP, etc.25 Historia de los entornos de prueba o Sandbox Un sandbox, en el contexto de desarrollo de software o desarrollo web, es un entorno de pruebas o cerrado que aísla los cambios en el código, fruto de la experimentación, del propio entorno de producción. El sandbox protege en tiempo real los servidores de datos, y hace de control preventivo de la ejecución de código fuente, datos o contenido, evitando unos cambios que podrían ser perjudiciales (independientemente de la intención del autor de los mismos) para un sistema, o que simplemente, podrían ser cambios de difícil reversión. Antes de 1956. Periodo orientado a debugging. “En este momento todas las pruebas que se realizaban estaban orientadas a la corrección directa del código fuente de los programas. Eran realizadas directamente por los programadores y no estaba clara la diferencia entre: checkout, debugging y testing”. Turing, A. (1949): Checking a Large Routine, p. 5. 2. Entre 1957 y 1978. Periodo orientado a demostración. “En este momento las pruebas se centran en la realización de checkouts exhaustivos que se focalizan en dos aspectos clave. Por un lado, hay que asegurar que el programa funciona (Debugging) y por otro asegurar que el programa resuelve el problema (Testing)”. C. Baker. (1957). Review of D.D. McCracken’s Digital Computer Programming.. 25. Gonzales, C, (s, f). Historia de los entornos integrados. Recuperado de: https://www.timetoast.com/timelines/historia-de-los-entornos-integrados-de-desarrollo-ide. 37.