• Author / Uploaded
• Digital Harbor Bolivia

Citation preview

UNIVERSIDAD MAYOR DE SAN SIMON FACULTAD DE CIENCIAS Y TECNOLOGIA DIRECCIÓN DE POSGRADO

“LOS ROLES DEL DEVOPS Y SUS HERRAMIENTAS”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES EMPRESARIALES VERSIÓN I .

POSTULANTE : HENRY ADOLFO VARGAS OVANDO TUTOR

: Msg. VALENTIN LAIME ZAPATA

Cochabamba – Bolivia 2018

A mis padres

i

ii

Agradecimientos: A mis padres, por su incansable apoyo en todos los aspectos de mi vida. A Mi hija Camila, por llenarme el corazón de alegrías. A mi hermano Mirko, por su apoyo y mostrarme fortaleza en los momentos difíciles. A Mavel, por su confianza. Al Ing. Rolando Linares, por su paciencia y grandes consejos. A mis amigos, por su apoyo y consejos.

¡Muchas gracias!

iii

iv

Contenido Resumen.......................................................................................................................................... 1 Introducción ..................................................................................................................................... 2 1

Generalidades .......................................................................................................................... 3 1.1

Antecedentes Generales .................................................................................................. 3

1.2

Antecedentes Específicos ................................................................................................ 3

2

Metodología .............................................................................................................................. 3

3

Roles DevOps .......................................................................................................................... 3

4

3.1

El DevOps evangelista ..................................................................................................... 4

3.2

Administrador de lanzamiento .......................................................................................... 4

3.3

Arquitecto de automatización ........................................................................................... 4

3.4

Desarrollador/Tester de Software..................................................................................... 5

3.5

Asegurador de experiencia (XA) profesional ................................................................... 5

3.6

Ingeniero de seguridad ..................................................................................................... 6

3.7

Jugador de tecnología de utilidad..................................................................................... 6

Herramientas DevOps.............................................................................................................. 7 4.1

Gestión de la configuración .............................................................................................. 7

4.1.1

Herramientas de Gestión de la Configuración .......................................................... 7

4.1.2

Algunas conclusiones en herramientas de Gestión de la Configuración ............... 18

4.2

Control de versiones ....................................................................................................... 18

4.2.1

Local vs Centralizado vs Distribuido ....................................................................... 19

4.3

Infraestructura de automatización .................................................................................. 20

4.4

Aprovisionamiento del sistema ....................................................................................... 23

4.5

Gestión del ciclo de vida del hardware........................................................................... 24

4.6

Administración de Proyectos de Software ..................................................................... 26

4.7

Integración continua........................................................................................................ 28

4.7.1

Jenkins ..................................................................................................................... 29

4.7.2

TeamCity.................................................................................................................. 33 v

4.7.3

Gestor de Repositorios Binarios ............................................................................. 33

4.8

Automatización de pruebas y construcción.................................................................... 36

4.9

Entrega continua – Continuous Delivery ........................................................................ 37

4.10

Despliegue de aplicaciones ............................................................................................ 37

4.10.1

Maven ...................................................................................................................... 37

4.10.2

Gradle ...................................................................................................................... 40

4.11

Despliegue continuo - Continuous Deployment ............................................................. 41

4.11.1

AWS CodeDeploy.................................................................................................... 42

4.11.2

Docker...................................................................................................................... 42

4.12

Métricas ........................................................................................................................... 44

4.12.1 4.13

SonarQube .............................................................................................................. 45

Logging (Registros)......................................................................................................... 46

4.13.1

Graylog 2 ................................................................................................................. 47

4.14

Monitorización(Supervisión) ........................................................................................... 47

4.15

Alertas ............................................................................................................................. 48

4.16

Gestión Eventos.............................................................................................................. 49

5

Conclusiones .......................................................................................................................... 51

6

Bibliografía.............................................................................................................................. 53

vi

Tabla de Cuadros, Gráficos y Figuras Figura 1: Arquitectura CFEngine..................................................................................................... 8 Figura 2: Estados CFEngine. ........................................................................................................ 10 Figura 3: Arquitectura Puppet. ...................................................................................................... 11 Figura 4: Ciclo de vida de ejecución Puppet. ............................................................................... 12 Figura 5: Implementación Chef. .................................................................................................... 13 Figura 6: Arquitectura Ansible. ...................................................................................................... 15 Figura 7: Arquitectura SaltStack. .................................................................................................. 17 Figura 8: Arquitectura Subyacente de Vagrant............................................................................. 22 Figura 9: Ciclo de vida del hardware. ........................................................................................... 25 Figura 10: Arquitectura de Jira a un alto nivel. ............................................................................. 26 Figura 11: Típico Proceso de Integración contínua. ..................................................................... 28 Figura 12: Integración con complementos. Fuente: Edukera!...................................................... 30 Figura 13: Integración Continua con Jenkins. .............................................................................. 31 Figura 14: Arquitectura Jenkins. ................................................................................................... 32 Figura 15: Repositorio maven típico. ............................................................................................ 34 Figura 16: Esquema Nexus. .......................................................................................................... 35 Figura 17: Ciclo de vida predeterminado de maven. .................................................................... 40 Figura 18: Continuous Delivery vs Continuous Deployment. ....................................................... 41 Figura 19: Interfaces virtualización del kernel Linux. .................................................................... 43 Figura 20: SonarQube captura de pantalla................................................................................... 45

vii

Resumen Muchas organizaciones de IT buscan adoptar DevOps para mejorar su ritmo de desarrollo de software y darse cuenta de la agilidad empresarial que se deriva de la aceleración y agilización de las comunicaciones entre las operaciones y el desarrollo. Sin embargo, no hay una manera rápida o sencilla de lograr DevOps. Muchas organizaciones abordaron como una simple aplicación tecnológica pura, pero el camino exitoso comienza con las mejores personas en los roles correctos de DevOps con las habilidades adecuadas de DevOps y un interés permanente en colaborar. Los expertos en IT necesitan potenciar y emplear roles profesionales en evolución. Trabajando como un agente de cambio principal para supervisar la transición, estos roles de DevOps incluyen arquitectos de automatización, ingenieros de seguridad, gerentes de lanzamiento, expertos en aseguramiento de la experiencia, desarrolladores de pruebas y jugadores de tecnología de utilidad que entienden las operaciones y el desarrollo. Las herramientas para administrar infraestructuras nacen a partir de la expansión de las operaciones de los negocios en diferentes, para ello se usan herramientas ya existentes, así como también muchas de ellas fueron creadas recientemente, las cuales ofrecen apoyo en las diferentes actividades DevOps. Las herramientas son inherentes al trabajo realizado y a cómo se resuelven los problemas que se enfrentan cada día. El nivel de comodidad con el conjunto de herramientas que hay disponibles y la capacidad para adaptarse a las nuevas herramientas a medida que evolucionan y dan forma a los pensamientos e ideas. La disponibilidad de conocimiento colectivo, combinada con la colaboración a través de los límites de la organización y la compañía del software de código abierto, está cambiando dramáticamente el statu quo del trabajo. Empresas inmersas en la administración de la configuración de la infraestructura a mano con un número desconocido de sistemas divergentes e incapaces de responder y cambiar rápidamente y responder a las demandas del mercado tendrán como rivales a empresas que han logrado contener su complejidad en un eje a través de la automatización de la infraestructura. Si bien es posible administrar servidores a mano, o incluso escribir scripts de shell diseñados de forma artesanal, una herramienta de administración de configuración adecuada es invaluable, especialmente a medida que su entorno y equipo cambian. Palabras clave: DevOps, roles, herramientas, procesos, movimiento cultural.

1

Introducción Casi todas las organizaciones de IT (Information Technology – Tecnologías de Información) desean adoptar DevOps, con la promesa de una mayor velocidad de desarrollo de software y una mayor agilidad empresarial que se deriva de la racionalización y la aceleración de las interacciones entre el desarrollo y las operaciones. El problema es que no hay una manera fácil o rápida de llegar allí. "Muchas organizaciones recorrieron este camino, considerándolas como un juego de tecnología pura: consigamos una herramienta DevOps y la vida será mucho mejor", dice Rohit Antao. Esos esfuerzos a menudo fallan. Un viaje exitoso comienza con las personas adecuadas en los roles de DevOps correctos con las habilidades correctas y la voluntad de colaborar. Si bien adoptar roles nuevos o redefinidos no es en sí mismo suficiente para describir los roles DevOps, es un primer paso esencial. A menudo muchas organizaciones asignan miembros a sus nuevos equipos DevOps antes de que hayan comprendido y documentado completamente las habilidades requeridas para un equipo DevOps de alto rendimiento. No se dan cuenta de que no todo el personal tiene la visión o el deseo necesarios para tener éxito en un entorno altamente fluido y colaborativo". En general, el primer lugar en el que las personas buscan implementar cambios es a través de herramientas, enfatizaremos la importancia de examinar la colaboración, la contratación y la afinidad al principio de su proceso. Si bien las opciones de herramientas tienden a ser fáciles de obtener, pueden llevar a ocultar problemas en las interacciones entre los miembros del equipo y las culturas entre los equipos. Esto conduce a condiciones invisibles de falla a medida que la deuda cultural se acumula.

2

1

Generalidades

1.1

Antecedentes Generales

DevOps (acrónimo inglés de Development - desarrollo y Operations - operaciones) es una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev) y la operación del software (Ops). La principal característica del movimiento DevOps es defender enérgicamente la automatización y el monitoreo en todos los pasos de la construcción del software, desde la integración, las pruebas, la liberación hasta la implementación y la administración de la infraestructura. DevOps apunta a ciclos de desarrollo más cortos, mayor frecuencia de implementación, lanzamientos más confiables, en estrecha alineación con los objetivos comerciales. Como DevOps pretende ser un modo de trabajo interfuncional, en lugar de una sola herramienta de DevOps existen conjuntos (e inglés llamado toolchains) de múltiples herramientas. Se espera que tales herramientas de DevOps encajen en una o más de estas categorías, que reflejen los aspectos clave del proceso de desarrollo y entrega. 1.2

Antecedentes Específicos

El camino exitoso para una adopción DevOps comienza con la definición de roles clave con las mejores personas para esos roles con las habilidades y herramientas adecuadas. 2

Metodología

Para el presente trabajo se utilizarán los siguientes métodos de investigación: • •

Método Bibliográfico, debido a que se realizará la lectura y compilación de libros relacionados al tema de estudio. Método Analítico, debido a que se procederá a revisar y analizar ordenadamente documentos relacionados al tema de estudio.

3

Roles DevOps

Si bien abrazar roles nuevos o redefinidos no es en sí mismo suficiente para una transformación exitosa de DevOps, es un primer paso esencial. "En iniciativas no exitosas de DevOps, la organización no se da cuenta de que las personas son el componente más importante de la ecuación", dice Gerry Leitao, vicepresidente de entrega de servicios administrados y plataformas para la consultora de negocios Capgemini North America. "Estas organizaciones a menudo asignan miembros a sus nuevos equipos DevOps antes de que hayan comprendido y documentado completamente las habilidades técnicas y blandas requeridas para un equipo DevOps de alto rendimiento. No se dan cuenta de que no todo el personal tiene la visión o el 3

deseo necesarios para tener éxito en un entorno altamente fluido y colaborativo ". Mostraremos roles y conjuntos de habilidades relacionadas, que son fundamentales para cualquier organización que quiera adoptar un enfoque DevOps. 3.1

El DevOps evangelista

"Hay organizaciones de IT que han evolucionado para explotar las prácticas y capacidades de DevOps, y hay organizaciones de IT que están en proceso de hacerlo", dice Croker. "Esa evolución no sucederá por sí sola, y el papel vital aquí pertenece a la persona que va a poseer y entregar ese cambio". El evangelista de DevOps es el líder. Esta persona debe promover los beneficios de DevOps mediante la identificación y cuantificación de los beneficios comerciales que se derivan de la mayor agilidad que DevOps ofrece. Como agente de cambio, el evangelista de DevOps garantiza la aceptación de los equipos de desarrollo y operativos, identifica los roles clave para respaldar los métodos de entrega de DevOps y se asegura de que los profesionales de IT estén capacitados y capacitados para realizar esos cambios, dice Nagisetty. Además, el líder de su movimiento DevOps necesita eliminar el miedo al fracaso de la organización, dice Antao. "Tienes que construir una cultura que sea una cultura de aprendizaje en la que sea seguro fallar, fallar rápido, aprender de ella y mejorar". Croker está de acuerdo. "En una organización liderada por DevOps, hay algunos roles nuevos, pero es mucho más importante que se logre un cambio cultural para abordar los desafíos de la entrega de IT y las operaciones de IT existentes en los silos". Es fundamental para cualquier organización que quiera adoptar un enfoque DevOps exitoso. 3.2

Administrador de lanzamiento

Se llama a este rol administrador de lanzamiento, ingeniero de lanzamiento o administrador de estabilidad del producto, el enfoque es el mismo: "los gerentes de lanzamiento trabajan para abordar la gestión y coordinación del producto desde el desarrollo hasta la producción", dice Nagisetty. "Por lo general, trabajan en más detalles técnicos y obstáculos en los que no estaría involucrado un gerente de proyecto tradicional". Los gerentes de versiones supervisan la coordinación, integración y flujo de desarrollo, pruebas y despliegue para admitir la entrega continua. Están enfocados no solo en la creación, sino también en el mantenimiento de la cadena de herramientas de entrega de aplicaciones de extremo a extremo. 3.3

Arquitecto de automatización

Debido a que DevOps se basa en gran medida en los sistemas automatizados, esta función es clave. A veces llamados especialistas en integración, los arquitectos de automatización analizan, 4

diseñan e implementan estrategias para implementaciones continuas y garantizan una alta disponibilidad en los sistemas de producción y preproducción. Los arquitectos de automatización tienen un rol de automatización integral en todas las herramientas de DevOps y plataformas en la nube. Este rol también puede abarcar el pensamiento lean en procesos clave de DevOps. El rol de arquitecto de automatización se vuelve crítico en el mundo de DevOps. "Las organizaciones de DevOps deben proporcionar un entorno extremadamente confiable, totalmente automatizado y libre de obstáculos". La posición es particularmente importante para las organizaciones distribuidas geográficamente. 3.4

Desarrollador/Tester de Software

El desarrollador de software está en el corazón de la organización DevOps. Bajo DevOps, el título de desarrollador de software puede seguir siendo el mismo, pero el nuevo rol de desarrollador/probador

de

software

aumenta

dramáticamente

el

alcance

de

las

responsabilidades. Los desarrolladores son responsables no solo de convertir los nuevos requisitos en código, sino también de las pruebas unitarias, la implementación y el monitoreo continuo. “No se limitan a crear código para una especificación y lo entregan por la pared al equipo de control de calidad" Si bien DevOps implica una colaboración más extensa entre los grupos de desarrollo y operaciones, a veces también se le conoce como DevTestOps, un nombre que refuerza la idea de que las pruebas son parte del proceso. Este cambio a menudo requiere pasar a pruebas más automatizadas para que la calidad no se vea afectada. "El problema es que los equipos aún piensan que pueden hacer pruebas manuales y seguir siendo ágiles. No se puede", dice Mizrachi. "Si necesita probar nuevas compilaciones todos los días y está haciendo pruebas manuales que duran dos semanas, se encuentra en una situación imposible. La calidad del producto generalmente se degrada hasta que la organización y los procesos cambian en consecuencia". 3.5

Asegurador de experiencia (XA) profesional

Si bien la función de control de calidad (QA) a menudo forma parte del desarrollo de software, un nuevo tipo de control se vuelve necesario cuando las organizaciones adoptan DevOps. La necesidad de probadores de control de calidad se reemplaza por la necesidad de expertos en XA encargados de garantizar que todas las funciones y características nuevas se publiquen teniendo en cuenta la experiencia del usuario final. "La expectativa actual para los roles de control de 5

calidad es probar la funcionalidad, pero el rol debe evolucionar para incluir pruebas de experiencia de usuario". 3.6

Ingeniero de seguridad

En el desarrollo de la cascada tradicional, la seguridad del sistema es en gran medida una ocurrencia tardía. Es un "requisito no funcional" que, al igual que la garantía de calidad, suele incluirse al final del desarrollo del sistema. Las empresas con mentalidad de DevOps tienen ingenieros de seguridad que trabajan codo con codo con los desarrolladores, incorporando sus recomendaciones mucho antes en el proceso. "Construyen seguridad en el producto, no al final". 3.7

Jugador de tecnología de utilidad

Las operaciones tradicionales de IT o los profesionales de administración de sistemas se centran en mantener los servidores en funcionamiento. "En general, sus máquinas funcionan mejor cuando hay pocos cambios", dice Warren de Perforce. "Es probable que la causa más común de servicio interrumpido sean las aplicaciones que se ejecutan en esos servidores, por lo que los administradores introducen controles muy estrictos sobre lo que se permite que se ejecute en sus preciosos servidores. Requieren un control de calidad extenso en un entorno de prueba, entrega voluminosa y documentación de operaciones y lanzamientos muy infrecuentes". Los desarrolladores tradicionales han sido programadores de cabecera sin participación en sistemas de postproducción. El entorno rápido de DevOps requiere una nueva generación. Esos expertos en operaciones o administración ahora se están involucrando a lo largo del proceso de desarrollo. "Hoy en día, no sería raro que estos expertos en operaciones, a veces denominados ingenieros de DevOps, participen en la planificación del sprint para garantizar que la calidad del servicio, la gestión de recursos o la seguridad se prioricen junto con los entregables". Ya sea que su fondo tradicional sea el desarrollo o las operaciones de IT, DevOps requiere miembros del equipo de servicios públicos que puedan operar de manera efectiva en todas las plataformas de desarrollo, herramientas, redes, servidores y bases de datos, e incluso en todo el desarrollo y soporte. Una transición efectiva al entorno DevOps tiene más que ver con las personas y con la forma en que trabajan juntas para ofrecer productos de una manera nueva que con la tecnología.

6

4

Herramientas DevOps

Se tratará las cuestiones y decisiones más comunes que existen de los diferentes tipos de herramientas y se presentara una visión objetiva del ecosistema de herramientas actual. 4.1

Gestión de la configuración

Las herramientas son inherentes al trabajo y a cómo se resuelve los problemas, el nivel de confort con las herramientas disponibles y la capacidad de adaptación a las nuevas herramientas a medida que evolucionan. Comenzó en la década de 1950 por el Departamento de Defensa de los Estados Unidos como una gestión técnica de la disciplina, la gestión de la configuración (GC) ha sido adoptada en muchas industrias. La gestión de la configuración es el proceso de establecer y mantener la coherencia del rendimiento, los atributos funcionales y físicos de algo a lo largo de su ciclo de vida. Esto incluye las políticas, procesos, documentación y herramientas necesarias para implementar

este

sistema

con

performance,

funcionalidad

y

atributos

consistentes.

Específicamente dentro de la industria de ingeniería de software, ITIL, IEEE, ISO y SEI ha propuesto un estándar para la gestión de la configuración. Al igual que con el término "DevOps", esto ha generado cierta confusión en la industria acerca de una definición común para la gestión de la configuración. Para asegurar un estándar común desde el cual partir, definimos la gestión de la configuración como el proceso de identificación, gestión, supervisión y auditoría de un producto a lo largo de toda su vida, incluidos los procesos, documentación, personas, herramientas, software y sistemas. 4.1.1

Herramientas de Gestión de la Configuración

Las herramientas de gestión de configuración deberían idealmente soportar múltiples sistemas operativos. Esta es la razón por la que los proveedores tienes desarrollado utilitarios de gestión de configuración para asistir a administradores del servidor a mantener la infraestructura y para asegurar los sistemas en una configuración óptima. Esto ayuda a al profesional de IT a comprender qué recursos están disponibles y alertarlos sobre la presencia de actualizaciones basadas en las aplicaciones que están utilizando. También ayuda a encontrar maneras de implementar cambios necesarios. Cuando se trata de encontrar buenas herramientas de administración de la configuración, el problema no es la falta de elección. El problema es que hay muchos, aquí tenemos a algunos de los mejores para los diferentes contextos.

7

4.1.1.1 CFEngine CFEngine es una herramienta de código abierto de gestión de la configuración escrito por Mark

Burgess. Proporciona configuración remota centralizada para la automatización de grandes sistemas informáticos, incluida la administración unificada de servidores, sistemas, usuarios, dispositivos integrados en red, dispositivos móviles y sistemas. Utiliza arquitectura clienteservidor, los cambios que se realizan en el servidor se propagan a los clientes, incluso si están apagados en el momento de la actuación, al arrancar verían que su nivel de configuración es menor y solicitarían la actualización al servidor. En la siguiente figura se puede apreciar un esbozo de la arquitectura de CFEngine:

Figura 1: Arquitectura CFEngine. Fuente: CFEngine.com

La automatización aporta valor cuando el número de servidores a controlar es importante (más de 20) y todos ellos comparten algo en común. De no ser así, no tiene mucho sentido utilizar este tipo de herramientas. Está pensada para solucionar problemas comunes a la gestión de un centro de datos, estas son algunas de sus principales ventajas: - Centralizar. CFEngine permite automatizar la gestión de toda una infraestructura Linux desde un único punto y con una única herramienta, esto lo convierte en una solución escalable: el esfuerzo necesario para gestionar 1 máquina es el mismo que para 100.000. - Reducir errores. La automatización elimina tareas repetitivas y como consecuencia directa se evitan errores humanos reduciendo incidencias y mejorando la estabilidad de los servicios. El 8

diseño de CFEngine basado en la “Promise Theory” permite propagar cambios de forma fiable y con garantías. - Ahorrar tiempo. Al automatizar tareas con CFEngine ahorramos tiempo de dos formas: 1) se reduce el tiempo necesario para la puesta en marcha de nuevos servicios y aplicar cambios -aquí es donde nace el concepto DevOps- y 2) al evitar tener que conectarse vía SSH a los servidores para “trabajar” manualmente, el administrador cuenta con más tiempo para su verdadero trabajo: mejorar la infraestructura evitando que errores conocidos vuelvan a ocurrir. - Documentación. El trabajo del administrador de sistemas queda “auto-documentado “: cada regla en CFEngine define una tarea. Generalmente la configuración de CFEngine se combina con un sistema de control de versiones (Git, Subversion, etc.), por lo que tendremos un registro completo de todos los cambios realizados históricamente en la infraestructura, información que podemos “reciclar” con herramientas tipo “cf-know” y convertirlas en documentación. Por ejemplo; cuando entra un nuevo empleado leyendo este código tendría una idea actualizada de la configuración de los sistemas. Como funciona CFEngine CFEngine es un sistema totalmente distribuido que le permite definir los estados deseados de todo, desde infraestructuras a gran escala hasta dispositivos pequeños. El agente ligero cf-agent se ejecuta localmente en cada recurso e intenta persistentemente converger hacia el estado deseado definido. Los estados reales de los recursos administrados están disponibles en registros y en una base de datos empresarial para el cumplimiento y la fácil elaboración de informes. El uso de CFEngine se puede describir en los siguientes 3 pasos simples. a. Definir el estado deseado Como usuario final, puede usar el lenguaje específico de dominio (DSL) de CFEngine para definir los estados deseados. CFEngine le permite definir una variedad de estados que van desde la administración de procesos hasta la implementación del software y la integridad de los archivos. Normalmente, todos los estados deseados se almacenan en archivos de texto .cf en uno o más puntos de distribución central, denominados Centros de Políticas CFEngine. b. Asegurar el estado actual CFEngine normalmente se ejecuta localmente en cada recurso administrado. Un recurso puede ser cualquier cosa, desde un servidor, un conmutador de red, una Raspberry Pi o cualquier otro dispositivo informático. CF-agent, el motor de ejecución, es autónomo, lo que significa que todas las evaluaciones se realizan en el nodo local. 9

Antes de cada ejecución, que por defecto es cada 5 minutos, el agente intenta conectarse a uno de los Centros de Políticas para verificar si ha habido actualizaciones de políticas. Tras las actualizaciones de la política, cf-agent descargará la política más reciente en su propio directorio, ejecutará una comprobación de sintaxis y, al comenzar, ejecutará con éxito. c. Verificar estado actual Cada vez que el agente se ejecuta, crea un registro de inventario local, estados del sistema y resultados de ejecución. Para los clientes empresariales, todos los datos también se almacenan en una base de datos local. CFEngine también almacena una gran cantidad de información de activos como software instalado, CPU, memoria, disco, actividad de red, etc. En cuanto a los resultados de ejecución, CFEngine puede tener 3 estados; Promesa cumplida, promesa reparada y promesa no mantenida. En la siguiente figura podemos apreciar los diferentes estados CFEngine.

Figura 2: Estados CFEngine. Fuente: CFEngine.com

Debido a la naturaleza autónoma de CFEngine, los sistemas se mantendrán continuamente incluso si el servidor está inactivo. Los agentes de CFEngine en los hosts intentarán de manera oportunista conectarse al servidor. Si falla, se aplicará la última política exitosa y como toda la evaluación es local, no importa si las características del host cambian y es necesario reconfigurarlas. CFEngine lo resolverá y garantizará el cumplimiento.

10

4.1.1.2 Puppet Puppet es una herramienta de gestión de la configuración de código abierto. Está escrito en Ruby y fue liberado bajo la Licencia GNU (GPL) hasta la versión 2.7.0 y después bajo la licencia Apache 2.0. Puppet Labs y Puppet fueron fundados por Luke Kanies en el 2005. El usuario describe los recursos del sistema y sus estados utilizando el lenguaje declarativo que proporciona Puppet. Esta información es almacenada en archivos denominados manifiestos Puppet. Puppet descubre la información del sistema a través de una utilidad llamada Facter, y compila los manifiestos en un catálogo específico del sistema que contiene los recursos y la dependencia de dichos recursos. Estos catálogos son ejecutados en los sistemas de destino. Arquitectura de Puppet El servidor Puppet está instalado en uno o más servidores y el agente Puppet está instalado en todas las máquinas que se quiere administrar. Los agentes Puppet se comunican con el servidor y obtienen instrucciones de configuración. Luego el agente aplica la configuración en el sistema y envía un informe de estado al servidor. Los dispositivos pueden ejecutar agentes Puppet como un “demonio”, que puede activarse periódicamente como una tarea cron o puede ejecutarse manualmente siempre que sea necesario. En la siguiente figura apreciamos la arquitectura:

Figura 3: Arquitectura Puppet. Fuente: puppet.com

Lenguaje de configuración: el lenguaje de programación Puppet es un lenguaje declarativo que describe el estado de un sistema informático en términos de "recursos", que representan las 11

estructuras subyacentes de la red y del sistema operativo. El usuario ensambla recursos en manifiestos que describen el estado deseado del sistema. Estos manifiestos se almacenan en el servidor y se compilan en las instrucciones de configuración para los agentes que lo soliciten. Abstracción de recursos: Puppet permite a los usuarios configurar sistemas de una manera independiente de la plataforma al representar los conceptos del sistema operativo como datos estructurados. En lugar de especificar los comandos exactos para realizar una acción del sistema, el usuario crea unos recursos, que luego Puppet traduce en instrucciones específicas del sistema que se envían a la máquina que se está configurando. Por ejemplo, si un usuario desea instalar un paquete en tres nodos diferentes, cada uno de los cuales ejecuta un sistema operativo diferente, simplemente puede declarar un recurso y Puppet determinará qué comandos deben ejecutarse basándose en los datos obtenidos de Facter, un programa que recopila datos sobre el sistema en el que se está ejecutando, incluido su sistema operativo, la dirección IP y alguna información de hardware. Los proveedores en el nodo usan datos de Facter y otros partes del sistema traducen los tipos de recursos del catálogo en instrucciones de máquina que realmente configurarán el nodo. Una transacción típica en puppet tiene las siguientes etapas:

Figura 4: Ciclo de vida de ejecución Puppet. Fuente: puppet.com

12

i.

Un agente envía datos del Facter al maestro.

ii.

Puppet crea un grafo de la lista de recursos y sus interdependencias que representa el orden en el que deben configurarse para cada cliente. El maestro envía el catálogo apropiado a cada nodo de agente.

iii.

El estado real del sistema se configura de acuerdo con el estado deseado descrito en el archivo de manifiesto. Si el sistema ya está en el estado deseado, Puppet no realizará ningún cambio lo que hará que las transacciones sean idempotentes.

iv.

Finalmente, el agente envía un informe al maestro que detalla los cambios realizados y los errores que se produjeron.

4.1.1.3 Chef Es una herramienta de administración de configuración de código abierto escrita en Ruby y Erlang por Adam Jacob. Utiliza un DSL delgado construido sobre Ruby. Este enfoque le permite a Chef proporcionar suficiente abstracción para facilitar el razonamiento sobre su infraestructura. Chef incluye una taxonomía incorporada de todos los recursos básicos que uno podría configurar en un sistema, además de un mecanismo definido para extender esa taxonomía utilizando todo el poder del lenguaje Ruby. Ruby fue elegida porque brinda la flexibilidad de usar tanto la taxonomía integrada simple como la capacidad de manejar cualquier ruta de personalización que su organización requiera. Chef se utiliza para agilizar la tarea de configurar y mantener los servidores de una empresa, y puede integrarse con plataformas basadas en la nube como Amazon EC2, Google Cloud Platform, Oracle Cloud, Microsoft Azure y otros para aprovisionar y configurar automáticamente nuevas máquinas. Este diagrama muestra cómo desarrolla, prueba e implementa el código Chef.

Figura 5: Implementación Chef. Fuente: https://docs.chef.io/chef_overview.html

13

La estación de trabajo Chef es el lugar donde los usuarios interactúan con Chef, pueden crear y probar “recetas” utilizando herramientas tales como Test Kitchen e interactuar con el servidor Chef. Los nodos cliente de Chef son las máquinas que gestiona Chef. El cliente Chef se instala en cada nodo y se usa para configurar el nodo en el estado deseado. El servidor Chef actúa como una central para la configuración de datos. El servidor de Chef almacena las “recetas”, las políticas que se aplican a los nodos y los metadatos que describen cada nodo registrado que está siendo administrado. Los nodos usan el cliente Chef para pedirle al servidor Chef los detalles de configuración, como recetas, plantillas y distribuciones de archivos. 4.1.1.4 Ansible Ansible es un software que automatiza el aprovisionamiento de software, la gestión de configuraciones y el despliegue de aplicaciones. Permite a los gestionar servidores, configuraciones y aplicaciones de forma sencilla, robusta y paralela. Ansible gestiona sus diferentes nodos a través de SSH y únicamente requiere Python en el servidor remoto en el que se vaya a ejecutar para poder utilizarlo. Usa YAML para describir acciones a realizar y las configuraciones que se deben propagar a los diferentes nodos. No utiliza agentes ni infraestructura de seguridad personalizada adicional, por lo que es fácil de implementar y, lo que es más importante, utiliza un lenguaje muy simple (YAML, en forma de Ansible Playbooks) que le permite describir sus trabajos de automatización de una manera que se acerca al inglés simple. Como funciona Ansible Ansible no divide su proceso en pasos o procedimientos. Sin embargo, para comprender cómo funciona el software, analizaremos en cuatro etapas; Configuración de la arquitectura, claves SSH y su función, Gestión de inventario y uso de Ansible. A. Configuración de la arquitectura Ansible conecta nodos y empuja pequeños programas llamados ‘Ansible Modules'. Estos módulos actúan como el recurso para el estado deseado del sistema. Ansible ejecuta estos módulos y los elimina una vez que se completa la ejecución. Como usuarios, solo tenemos que trabajar en nuestro terminal, editor de texto y en algunos casos, un controlador de versiones para realizar un seguimiento de los cambios. 14

En la Figura 6 podemos observar un esquema de la arquitectura de Ansible:

Figura 6: Arquitectura Ansible. Fuente: Ansible.com

B. Las claves SSH y su función. Las claves SSH se promocionan como la mejor manera de acceder a Ansible. Sin embargo, se puede elegir otras opciones como Kerberos. Las claves de autorización son compatibles y pueden controlar el acceso de diferentes módulos a diferentes usuarios, lo que será útil en muchos sistemas de IT. C. Gestión de inventario Ansible pone todas las máquinas que está administrando en un sistema en un archivo INI simple. Las máquinas se agrupan según la elección del usuario dentro del archivo INI. Se pueden agregar nuevas máquinas sin ningún tipo de firma SSL, lo que también elimina los problemas de NTP o DNS. Además de eso, Ansible puede conectarse fácilmente a fuentes como Rackspace, EC2, Openstack y otras. D. Usando Ansible Una vez que su instancia esté disponible, puede comenzar a usar Ansible sin siquiera nada adicional. Todos los requisitos en forma de módulos de recursos y comandos en ejecución ya han sido atendidos.

15

Características clave de Ansible: Modela la infraestructura de IT en torno a los sistemas interrelacionados entre sí, asegurando así resultados finales más rápidos. La biblioteca de módulos puede residir en cualquier sistema, sin el requisito de ningún servidor, demonios o bases de datos. No se requiere configuración adicional, así que una vez que tenga la instancia lista, puede trabajar en ella de inmediato. Es más fácil y rápido de implementar, ya que no depende de agentes o infraestructura de seguridad personalizada adicional. Utiliza una estructura de lenguaje muy simple llamada playbooks. Los playbooks son muy parecidos al inglés sencillo, estos describen los trabajos de automatización. Ansible tiene la flexibilidad de permitir que los módulos hechos por el usuario se puedan escribir en cualquier lenguaje de programación como Ruby, Python. También permite agregar nuevos comportamientos del lado del servidor extendiendo los tipos de conexión de Ansible a través de las API de Python. 4.1.1.5 SaltStack SaltStack es una herramienta de gestión de la configuración y orquestación escrita por Thomas Hatch, es de código abierto y funciona en un modelo de cliente-servidor o en un modelo no centralizado. Utiliza un repositorio central para aprovisionar nuevos servidores y otras infraestructuras de IT, para realizar cambios en los existentes e instalar software en entornos de IT, incluidos los servidores físicos y virtuales, así como la nube. SaltStack se basa en el lenguaje de programación Python, proporciona métodos push y SSH para comunicarse con los clientes. SaltStack permite agrupar clientes y plantillas de configuración para que el control del entorno sea simple y fácil. SaltStack automatiza las tareas administrativas repetidas del sistema y la implementación del código, eliminando los procesos manuales de una manera que puede reducir los errores que ocurren cuando las organizaciones de IT configuran los sistemas.

16

A. Arquitectura de SaltStack

Figura 7: Arquitectura SaltStack. Fuente: http://www.yet.org

Salt se utiliza en las organizaciones de DevOps porque extrae el código de desarrollador y la información de configuración de un repositorio de código central y envía ese contenido de forma remota a los servidores. Los usuarios de Salt pueden escribir sus propios scripts y programas, y pueden descargar configuraciones precompiladas que otros usuarios han contribuido a un repositorio público. B. Características principales -

Flexibilidad: Puede ser adaptada a diferentes arquitecturas y modelos de desarrollo empresarial, desde una red de topología sencilla hasta soluciones para centros de procesos de datos.

-

Velocidad: SaltStack ofrece soluciones de gestión de forma fácil y eficaz a bajo coste.

-

Escalabilidad: SaltStack tiene la capacidad de soporte y crecimiento en múltiples plataformas, para gestionar fácilmente. Salt Cloud se integra con muchos otros proveedores de la nube como Google Cloud, AWS, etc., por lo que es fácil aprovechar todos los activos con un solo comando. 17

4.1.2

Algunas conclusiones en herramientas de Gestión de la Configuración

Existen variedad de herramientas de gestión de la configuración, es importante investigar y seleccionar la mejor herramienta que sea adecuada para una organización. Las organizaciones de pequeña o mediana escala en general buscan una herramienta de código abierto y la más efectiva que puede ser beneficiosa para su organización, ya que tienen menos fuerza laboral y financiera. Las herramientas de configuración CFEngine, Chef, Rudder y Bamboo serían una buena opción, ya que son de código abierto, altamente escalables, robustas y seguras. Pero también están siendo utilizados por empresas de gran envergadura. Mantenimiento y configuración es fácil. Se basan en los lenguajes de programación más utilizados, como Java y .net. Son compatibles con múltiples funcionalidades y múltiples plataformas de sistemas operativos. Estas herramientas admiten la adopción de la nube, así como la compatibilidad con 24 * 7. Las industrias a gran escala se centran principalmente en la robustez, la disponibilidad, la seguridad y el soporte. La mayoría de las compañías grandes prefieren CFEngine, Ansible, Chef versión empresarial, Octopus, TeamCity, etc. Estas herramientas proporcionan un proceso de implementación confiable y admiten múltiples plataformas de SO. Son de código abierto y, si la empresa desea los beneficios extendidos, puede optar por la versión empresarial. Estas herramientas poseen múltiples características, granularidad y orquestación, interoperabilidad y se requiere una curva de aprendizaje mínima. 4.2

Control de versiones

El control de versiones registra los cambios en archivos o conjuntos de archivos almacenados dentro del sistema. Puede tratarse de código fuente y otros documentos que pueden formar parte de un proyecto de desarrollo de software. Los desarrolladores realizan cambios en grupos llamados compromisos (del inglés commit) o revisiones. Cada revisión junto con los metadatos, como quién realizó el cambio y cuándo, se almacena dentro del software en función de la implementación del control de versión. Los sistemas de control de versiones se pueden clasificar por el proceso de almacenamiento de los metadatos y las revisiones: local, centralizado o distribuido. Si bien el funcionamiento interno de los sistemas de control de versiones está más allá del alcance de este documento, comprender el concepto general de control de versiones y las limitaciones de los diferentes modelos, ya que influyen en la colaboración y la afinidad de los miembros del equipo, es importante para entender el impacto en el desarrollo de software. 18

4.2.1

Local vs Centralizado vs Distribuido

El control de versión local se administra guardando conjuntos de diferencias en archivos en un solo nodo local donde se almacenan los archivos. El control de versiones centralizado se administra a través de un único servidor remoto que contiene todos los archivos versionados. Los clientes desprotegen archivos desde esta ubicación centralizada. El control de versión distribuido se administra a través de repositorios completos que se replican en diferentes nodos. Tener la capacidad de comprometer (commit), comparar, fusionar y restaurar revisiones pasadas de objetos al repositorio permite una cooperación y colaboración más ricas dentro de los equipos y entre ellos. Minimiza los riesgos al establecer una forma de revertir los objetos en producción a versiones anteriores. GIT Diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran implementar la interfaz de usuario, sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. El mantenimiento del software Git está actualmente supervisado por Junio Hamano, quien recibe contribuciones al código de alrededor de 280 programadores. Características principales de Git Fuerte apoyo al desarrollo no lineal, por ende, rapidez en la gestión de ramas y mezclado de diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de desarrollo no lineal. Una presunción fundamental en Git, es que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores que lo revisan. Gestión distribuida, Git le da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados en la misma manera que se hace con la rama local. 19

Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y módulos IDE para CVS pre-existentes en el acceso de repositorios Git. Todas las versiones previas a un cambio determinado, implican la notificación de un cambio posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial). Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles y desastrosas coincidencias de ficheros diferentes en un único nombre. Re-almacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en diferencias) no ocurre cada cierto tiempo. Subversion A principios del año 2000, CollabNet comenzó a desarrollar el software libre Subversion y publicaría cuatro años más tarde su primera versión. Con ello, SVN se unió al modelo CVS. En 2009, el proyecto se trasladó a la Fundación Apache, motivo por el cual es conocido actualmente como Apache Subversion. SVN se basa en un sistema de control de versiones centralizado. Existe un repositorio de datos central de accesible a todos los usuarios. Dado que los cambios realizados no pueden ser fusionados entre sí, el sistema evita que dos usuarios puedan editar un mismo archivo al mismo tiempo. El proceso es muy simple, cuando uno de los usuarios accede a un archivo, el sistema lo marca automáticamente como de solo lectura para los demás. Además, Apache Subversion ofrece la posibilidad de descargar y editar directorios individuales sin depender del árbol general de directorios. De esta manera, es posible asignar diferentes permisos de lectura y escritura a los diferentes usuarios. Subversion se caracteriza también porque puede registrar directorios vacíos, renombrados y mudados de sitio sin pérdidas de su historia. 4.3

Infraestructura de automatización

La infraestructura de automatización está creando sistemas que reducen la carga de las personas para administrar servicios y aumentan la calidad, exactitud y precisión de un servicio para los consumidores de un servicio. 20

Ejemplo: Convergencia vs Congruencia La convergencia se define como el proceso de llegar a un estado final deseado basándose en el cálculo de la ruta desde el punto de inicio actual. Si hay una falla, otra ronda de ejecución aún se esforzará por alcanzar el estado final deseado al volver a calcular la ruta sin revertir los cambios y comenzar desde el principio. La congruencia comienza a partir de una pizarra en blanco y sigue una secuencia de pasos para aplicar un sistema a un estado deseado. Vagrant Es una herramienta de código abierto para crear y mantener entornos de desarrollo de software virtuales portátiles. Se ejecuta sobre soluciones de VM como VirtualBox, Hyper-V, contenedores Docker, VMware y AWS que intentan simplificar la administración de la configuración de software de las virtualizaciones para aumentar la productividad del desarrollo. Vagrant está escrito en el lenguaje Ruby, pero su ecosistema admite el desarrollo en algunos lenguajes. Utiliza un archivo de configuración llamado Vagrantfile, que contiene todas las configuraciones necesarias para la VM. Una vez que se crea una máquina virtual, se puede compartir con otros desarrolladores para tener el mismo entorno de desarrollo. Vagrant tiene complementos para el aprovisionamiento en la nube, herramientas de administración de configuración (chef, Puppet, etc.) y Docker. Arquitectura de Vagrant Vagrant utiliza "Provisioners" y "Providers" como bloques de construcción para administrar los entornos de desarrollo. Los aprovisionadores son herramientas que permiten a los usuarios personalizar la configuración de los entornos virtuales. Puppet y Chef son los dos aprovisionadores más utilizados en el ecosistema Vagrant (Ansible disponible desde el 2014). Los proveedores son los servicios que Vagrant utiliza para configurar y crear entornos virtuales. Vagrant se sitúa sobre el software de virtualización como un envoltorio y ayuda al desarrollador a interactuar fácilmente con los proveedores. Automatiza la configuración de entornos virtuales mediante Chef o Puppet, y el usuario no tiene que usar directamente ningún otro software de virtualización. Los requisitos de la máquina y el software están escritos en un archivo llamado "Vagrantfile" para ejecutar los pasos necesarios para crear un cuadro listo para el desarrollo. "Box" es un formato y una extensión para entornos Vagrant que se copian en otra máquina para replicar el mismo entorno. Para comprender cómo funciona Vagrant, es necesario sumergirse en la arquitectura subyacente de Vagrant. 21

La organización de los módulos y su acoplamiento se muestran en la siguiente figura.

Figura 8: Arquitectura Subyacente de Vagrant. Fuente: https://delftswa.github.io/chapters/vagrant

Capa central (Core layer) La capa central consiste en el núcleo más interno de Vagrant. Especifica los componentes principales del sistema, como una máquina, que representa una interfaz con la máquina virtual real. Además, especifica las interfaces, que los complementos pueden extender. Por ejemplo: el complemento del proveedor VirtualBox en la capa de complementos extiende la interfaz del proveedor en la capa central.

22

Capa de plugin La mayor parte del núcleo de Vagrant se implementa mediante complementos. Dado que Vagrant tiene su propio complemento API, uno puede estar seguro de que la interfaz es estable y está bien soportada. Esto significa, además, que el núcleo en sí es relativamente pequeño y carece de la funcionalidad más necesaria de Vagrant. La funcionalidad real se implementa en la capa de complementos mediante complementos que proporcionan su funcionalidad al construir sobre los módulos en la capa central. En la figura, las interfaces como el comando, el aprovisionador y el invitado, que se pueden ampliar. Por ejemplo: para la interfaz del aprovisionador, la implementación de Docker, Puppet y Chef son visibles. Usando este tipo de vista, es fácil ver cómo las implementaciones en la capa de complemento se relacionan con las interfaces y la funcionalidad central en la capa central.

4.4

Aprovisionamiento del sistema

Una vez que se tuvo un plan para comprar y suministrar hardware en los centros de datos. Ahora, las empresas tienen la opción de invertir en infraestructura en la nube con la opción de computación bajo demanda, donde compra solo lo que necesitan y aumentan o disminuyen según sea necesario. La automatización de la infraestructura permite la definición y el control de cómo se configura un sistema determinado para que se describa en código, de la configuración del sistema hasta los programas que se instalan y se ejecutan para la administración de usuarios y la configuración de red. Los beneficios de describir la infraestructura como código incluyen procesos repetibles, consistentes, documentados y residentes que soportan cierta cantidad de fallas. Esto libera tiempo, mejora la eficiencia del personal, permite más flexibilidad y medición de riesgos. También aumenta el grado de confianza que tienen las personas en la configuración e implementación de la máquina, lo que reduce la cantidad de tiempo dedicado a la depuración de problemas según las diferencias del sistema. La automatización del aprovisionamiento es una extensión de la automatización de la infraestructura que permite a las empresas definir la infraestructura en términos de los grupos de sistemas dependientes necesarios para definir su infraestructura y no solo los nodos individuales. Permite a las personas especificar cómo desean que un grupo de servidores se aprovisione una vez, y luego usar esa especificación automáticamente tantas veces como lo deseen más adelante. Frecuentemente los diferentes fabricantes de hardware de servidor como HP y Dell 23

proporcionarán una herramienta de aprovisionamiento que solo funcionará con su marca de hardware, pero también hay soluciones de código abierto disponibles. Las diferentes distribuciones de Linux también proporcionarán herramientas específicas para el sistema operativo. Como ejemplo, Cobbler y Kickstart pueden utilizarse para automatizar el aprovisionamiento de sistemas que ejecutan Red Hat Enterprise Linux o CentOS. El personal de operaciones puede escribir archivos "Kickstart" que pueden especificar la partición del disco duro, la configuración de la red, qué paquetes de software instalar y mucho más. Incluso se pueden hacer herramientas de automatización de aprovisionamiento para instalar y configurar la configuración de la infraestructura. De esta manera, la creación y administración de servidores se puede automatizar casi completamente de un extremo a otro, lo que reduce el tiempo requerido para hacer las tareas repetitivas de hacer clic en las tediosas pantallas de instalación. Las computadoras se adaptan mucho mejor a estas tareas que los humanos, lo que reduce los errores y garantiza la consistencia en el producto entregado. Algunas herramientas de automatización de infraestructura se han ampliado para proporcionar esta funcionalidad. Chef Provisioning, que se incluye en Chef Developer Kit, permite definir todo el conjunto de sistemas, incluido el hardware, la red y el software. Cobbler Cobbler es un servidor de aprovisionamiento de Linux que facilita y automatiza la instalación de varios sistemas operativos de sistemas basados en la red desde un punto central utilizando servicios como DHCP, TFTP y DNS. Puede configurarse para PXE, reinstalaciones e invitados virtualizados utilizando Xen, KVM o VMware. Cobbler interactúa con el programa koan para la reinstalación y el soporte de virtualización. koan y Cobbler utilizan libvirt para integrarse con diferentes softwares de virtualización. Cobbler se basa en el mecanismo “Kickstart” y ofrece perfiles de instalación que se pueden aplicar a una o varias máquinas. 4.5

Gestión del ciclo de vida del hardware

Los DevOps tienen lidiar con la gestión del ciclo de vida del hardware de una u otra forma, aunque la llegada de la nube y la infraestructura o los servicios de plataforma ha reducido la cantidad de atención que esto requiere en cierta medida. El ciclo de vida del hardware comienza con la planificación y la compra (o el arrendamiento), continúa con la instalación, el mantenimiento y la reparación, y termina con el intercambio, devolución o reciclaje del hardware que ha llegado al final de su vida útil. 24

En la siguiente figura podemos apreciar una vista general del ciclo de vida del hardware.

Figura 9: Ciclo de vida del hardware. Fuente: http://novanetworks.com/services/technical-services/lifecycle-management-services

Las herramientas de automatización de aprovisionamiento reducen en gran medida la cantidad de trabajo manual que se debe realizar durante la instalación del hardware y después del mantenimiento del hardware. Sin ello, la instalación de nuevo hardware significaría la configuración manual por parte de los administradores del sistema o los técnicos del centro de datos, como todo trabajo repetitivo, tiende a ser propenso a errores. La automatización de los pasos de aprovisionamiento hace que traer hardware nuevo sea más confiable además de ser mucho más rápido. Esta misma automatización puede ayudar en la reparación y mantenimiento. Si un servidor debe salir de producción para algo como reemplazar un módulo de memoria defectuoso o actualizar un disco duro, la automatización del aprovisionamiento y el estado del servidor pueden garantizar que se vuelva a poner en producción en el mismo estado, con la misma configuración, como fue cuando se retiró, o si un servidor necesita ser reconstruido completamente, se puede hacer fácilmente. Si es necesario seguir un proceso en particular para el mantenimiento o la desactivación del hardware, también se puede automatizar, liberando los recursos del administrador del sistema para centrarse en un trabajo más intensivo. 25

4.6

Administración de Proyectos de Software

El software de gestión de proyectos se refiere a las aplicaciones que fueron diseñadas para facilitar la entrega de proyectos y hacerlos más eficientes. Al utilizar un sistema de gestión de proyectos, puede establecer hitos y plazos más realistas, enlazar y automatizar las tareas interdependientes y mantener a todos los miembros de su equipo centrados en sus entregables. El software de gestión de proyectos generalmente ofrece señales visuales como los gráficos y las herramientas de seguimiento de recursos y tiempo. Jira JIRA es una herramienta en línea para la administración de tareas de un proyecto, el seguimiento de errores e incidencias y para la gestión operativa de proyectos. La herramienta fue desarrollada por la empresa australiana Atlassian. Inicialmente Jira se utilizó para el desarrollo de software, sirviendo de apoyo para la gestión de requisitos, seguimiento del estado de desarrollo y más tarde para la gestión de errores. Jira puede ser utilizado para la gestión y mejora de los procesos, gracias a sus funciones para la organización de flujos de trabajo. En la siguiente figura se aprecia la arquitectura de Jira a un alto nivel.

Figura 10: Arquitectura de Jira a un alto nivel. Fuente: Jira Essentials

26

Características de Jira

Seguimiento de errores Seguimiento de problemas Gestión de proyectos Paneles de control Flujo de trabajo Gadgets Informes y gráficos Capacidades de búsqueda Integración Acceso y Notificaciones Multi-lenguaje Seguridad Fácil Navegación

Wrike Wrike es un software de gestión de proyectos y colaboración online diseñado para gestionar la carga de trabajo en empresas y organizaciones de distintos tamaños. El software está disponible en tres versiones: Gratis, Profesional y Empresa. Ofrece la posibilidad de crear tareas, asignarlas, marcarlas como completadas y compartir archivos. La versión gratuita permite un número ilimitado de usuarios, mientras que tan solo 5 usuarios pueden crear, asignar y tener acceso a las tareas. La versión Profesional incorpora diagramas de Gantt, seguimiento de tiempo y la opción de compartir archivos arrastrándolos, también ofrece compatibilidad mediante API, entre otras funciones. La versión Empresa incorpora datos y análisis en tiempo real y la posibilidad de asignar distintos grupos de trabajo a los usuarios (entre otras muchas funcionalidades). Wrike también está disponible para dispositivos iOS 10.00 o posteriores, también compatible con iPhone, iPad, iPod touch y Android 4.0 o superior. Todas las versiones incorporan un flujo de actividad que informa a los usuarios sobre cualquier tipo de acción llevada a cabo por otros usuarios pertenecientes a un grupo de trabajo específico. 27

El software de Wrike también incorpora funciones sociales. Wrike también está integrado con otros programas como Google Apps, Microsoft Outlook, Microsoft Excel, Microsoft Project, Google Drive, Dropbox, Apple Mail, Box, IBM Connections, entre otros.

4.7

Integración continua

La integración continua (CI) es el proceso de integración de un nuevo código escrito por desarrolladores con una línea principal o una rama "maestra" con frecuencia a lo largo del día. Esto contrasta con que los desarrolladores trabajen en ramas de funciones independientes durante semanas y meses a la vez, solo fusionando su código de nuevo con la rama maestra cuando se terminó por completo, los largos períodos de tiempo entre las integraciones significan que se ha cambiado mucho más, aumentando la probabilidad de que algunos de esos cambios se estén con errores. Con los conjuntos de cambios más grandes, es mucho más difícil aislar e identificar qué causó que algo deje de funcionar. Con los conjuntos de cambios pequeños, frecuentemente integrados, encontrar el cambio específico que causó un error es mucho más fácil y también hacer una oportuna regresión. El objetivo es evitar este tipo de problemas de integración que provienen de fusiones grandes e infrecuentes. La figura muestra el típico proceso de CI.

Figura 11: Típico Proceso de Integración Contínua. Fuente: https://developers.redhat.com

28

Para asegurarse de que las integraciones fueron exitosas, los sistemas de CI generalmente ejecutarán una serie de pruebas automáticamente al fusionarse de nuevos cambios. Cuando estos cambios se confirman y se combinan, las pruebas comienzan a ejecutarse automáticamente para evitar la sobrecarga de las personas que tienen que acordarse de hacerlo, ya que cuanta más sobrecarga requiere una actividad, menos probable es que se realice, especialmente cuando las personas están en apuradas. El resultado de estas pruebas a menudo se visualiza, donde "verde" significa que las pruebas se aprobaron y que la compilación recién integrada se dice que está limpia, y las pruebas que fallan o "rojas" significan que la compilación falló y debe repararse. Con este tipo de flujo de trabajo, los problemas se pueden identificar y solucionar mucho más rápido.

4.7.1

Jenkins

Jenkins es una herramienta de automatización de código abierto escrita en Java con complementos creados para propósitos de integración continua que está basado en el proyecto Hudson. Jenkins se utiliza para crear y probar sus proyectos de software continuamente, lo que facilita que los desarrolladores integren los cambios en el proyecto y facilita que los usuarios obtengan una versión nueva. También le permite entregar continuamente su software al integrarse con una gran cantidad de tecnologías de prueba y despliegue. Con Jenkins, las organizaciones pueden acelerar el proceso de desarrollo de software a través de la automatización. Jenkins integra procesos de ciclo de vida de desarrollo de todo tipo, incluyendo compilación, documentación, pruebas, empaquetado, despliegue, análisis estático y mucho más. Jenkins logra una integración continua con la ayuda de complementos. Los complementos permiten la integración de varias etapas de DevOps. Si desea integrar una herramienta en particular, necesita instalar los complementos para esa herramienta. Por ejemplo: Git, proyecto Maven 2, Amazon EC2, editor HTML, etc.

29

La siguiente figura muestra que Jenkins está integrando varias etapas de DevOps:

Figura 12: Integración con complementos. Fuente: Edukera!

4.7.1.1 Integración continua con Jenkins Imaginemos un escenario donde el código fuente completo de la aplicación fue construido y luego desplegado en el servidor de prueba para la prueba. Parece una forma perfecta de desarrollar un software, pero este proceso tiene fallas: -

Los desarrolladores deben esperar hasta que se desarrolle el software completo para los resultados de las pruebas.

-

Existe una alta posibilidad de que los resultados de la prueba puedan mostrar múltiples errores. Es difícil para los desarrolladores ubicar esos errores porque tienen que verificar todo el código fuente de la aplicación.

-

Se ralentiza el proceso de entrega de software.

-

La retroalimentación continúa relacionada con elementos como la codificación o problemas de arquitectura, fallas de compilación, estado de prueba y carga de versiones 30

de archivos se pierde debido a que la calidad del software puede disminuir. -

Todo el proceso fue manual, lo que aumenta el riesgo de fallos frecuentes.

Es evidente por los problemas indicados que no solo el proceso de entrega del software se hizo lento, sino que la calidad del software también disminuyó. Por lo tanto, para superar este caos, existía una gran necesidad de un sistema en el que los desarrolladores puedan desencadenar continuamente una compilación y una prueba para cada cambio realizado en el código fuente. Jenkins es la herramienta de CI más madura disponible, en la figura se aprecia cómo la integración continua con Jenkins superó las deficiencias anteriores.

Figura 13: Integración Continua con Jenkins. Fuente: Edukera!

4.7.1.2 Arquitectura de Jenkins El servidor Jenkins es un panel de control web que es alimentado desde un archivo war, usando el panel se puede configurar los trabajos/proyectos, pero la construcción tiene lugar en Nodos/Esclavo. Por defecto, un Nodo está configurado y ejecutándose en el servidor Jenkins. También se puede agregar más nodos usando la dirección IP, el nombre de usuario, la contraseña usando los métodos ssh / jnlp / webstart. El servidor principal Jenkins es el maestro y gestiona los trabajos de compilación programados, enviar las compilaciones a los esclavos para la ejecución real, monitorear a los esclavos (posiblemente tomándolos en línea y fuera de línea según sea necesario) y registrar y presentar los resultados de la compilación. Incluso en una arquitectura distribuida, una instancia maestra de Jenkins también puede ejecutar trabajos de compilación directamente. El trabajo de los esclavos es hacer lo que están configurados en el servidor Jenkins, que implica 31

ejecutar trabajos de compilación enviados por el maestro. Puede configurar un proyecto para que siempre se ejecute en una máquina esclava particular, o un tipo particular de máquina esclava, o simplemente deje que Jenkins elija la próxima esclava disponible.

Figura 14: Arquitectura Jenkins. Fuente: Continuous Delivery with Docker and Jenkins

4.7.1.3 Características de Jenkins Listo para correr fuera de la caja Solución de integración continua (CI) y entrega continua (CD) Complementos para Windows, Mac OS X y otros sistemas operativos similares a Unix Comprobación de errores sobre la marcha (pruebas continuas) Ayuda incorporada Puede integrarse con casi todas las herramientas debido a cientos de complementos y complementos en el Centro de actualizaciones Puede colocar una gran cantidad de proyectos o crear diferentes entornos. Proporciona seguridad 32

4.7.2

TeamCity

Es un servidor de integración y administración continua de la compilación basada en Java de JetBrains. Fue lanzado por primera vez el 2 de octubre de 2006. TeamCity es un software comercial y está licenciado bajo una licencia propietaria. Ofrece todas las funciones en su versión gratuita, pero está limitado a las 100 configuraciones de compilación y 3 agentes de compilación. Agentes de compilación adicionales y configuraciones de compilación deben ser comprados. Recientemente, JetBrains comenzó a ofrecer una versión de prueba en la nube de TeamCity en la que puede probarlo para un proyecto sin la molestia de tener que instalarlo en las instalaciones. Trabaja en muchas plataformas diferentes y tiene el soporte para una amplia variedad de herramientas y frameworks. Hay muchos complementos disponibles públicamente, desarrollados tanto por JetBrains como por terceros. 4.7.3

Gestor de Repositorios Binarios

Un gestor de repositorios binarios es una herramienta de software diseñada para optimizar la descarga y el almacenamiento de archivos binarios utilizados y producidos en el desarrollo de software. Centraliza la gestión de todos los artefactos binarios generados y utilizados por la organización para superar la complejidad que surge de la diversidad de los tipos de artefactos binarios, su posición en el flujo de trabajo general y las dependencias entre ellos. Un repositorio binario es un repositorio de software para paquetes, artefactos y sus metadatos correspondientes. Se puede usar para almacenar archivos binarios producidos por una organización, como lanzamientos de productos y compilaciones de productos nocturnas, o para binarios de terceros que deben tratarse de manera diferente por razones técnicas y legales. El desarrollo de software puede ser un proceso complejo ya que involucra a muchos desarrolladores, o equipos de desarrolladores que trabajan en base de código compartido, acceden a las mismas herramientas de compilación, descargan y usan un conjunto compartido de recursos binarios e implementan componentes en el mismo producto de software. Para administrar los archivos de origen utilizados en el desarrollo de software, las organizaciones generalmente usarán el control de revisión. Los muchos archivos de origen utilizados en el desarrollo de software finalmente se incorporan en los artefactos binarios (también conocidos como "binarios") que constituyen los componentes de un producto de software. Además, para proporcionar su funcionalidad y conjunto de funciones, los productos de software pueden usar muchos artefactos de terceros descargados de repositorios de código abierto gratuitos o comprados de fuentes comerciales. En consecuencia, un producto de software puede 33

comprender decenas, cientos e incluso miles de artefactos binarios individuales que deben gestionarse para mantener de manera eficiente un producto de software coherente y funcional. Esta función de administrar los artefactos binarios se realiza mediante un administrador de repositorio binario. La industria del software y la tecnología continúa cambiando y creciendo, los administradores de repositorios binarios no son diferentes. Están comenzando a cambiar hacia el posicionamiento como gestores de paquetes universales. Estos gestores de paquetes pretenden estandarizar la forma en que las empresas tratan todos los tipos de paquetes utilizados en el proceso de desarrollo de software. Brindan a los usuarios la capacidad de aplicar métricas de seguridad y cumplimiento en todos los tipos de artefactos. Se ha dice que los administradores de paquetes universales están en el centro de una cadena de herramientas DevOps. Algunos de los más importantes son: Apache Archiva, Cloudsmith Package, JFrog Artifactory, Inedo ProGet, Sonatype Nexus. Sonatype Nexus Es una herramienta que ayuda en la gestión de componentes, creación de artefactos y liberación de candidatos en todo su ciclo de vida de desarrollo. En Maven Central están almacenadas casi todas las librerías que puedas necesitar a la hora de desarrollar software. En la figura siguiente se muestra la forma en que se gestiona los repositorios con Maven central.

Figura 15: Repositorio maven típico. Fuente: http://www.javiergarzas.com

34

Nexus se utilizan para no tener que depender de algo externo siempre y poder mantener controladas las librerías propias de la empresa. Así, con un Nexus el esquema anterior pasaría a ser el siguiente:

Figura 16: Esquema Nexus. Fuente: http://www.javiergarzas.com

En este caso, al compilar o usar las librerías, maven primero buscará en el repositorio local, si no están ahí buscará en el repositorio Nexus y si no se irá a Maven Central y las instalará en Nexus. Las librerías propias de la empresa las subiremos directamente al Nexus. Este tipo de repositorios también se utilizan como caché. La idea de tener un Nexus o Artifactory, es que sean repositorios de librerías internos en la organización. Al estar en una red local, el acceso al Nexus será más rápido que tener que conectarme a Maven Central para descargar los artefactos. En ese sentido, si alguien del equipo tiene que compilar el código, y ciertas librerías de Maven Central no están en el Nexus, su maven hará que se descarguen e instalen esas librerías en Nexus. Cuando otra persona vuelva a compilar el código, ya no tendrá que bajarse las librerías de Maven Central, porque el maven de otro desarrollador ya lo hizo. Si el proyecto tiene muchas dependencias internas, es decir, cuando se compila este módulo se genera un artefacto que utilizo como base de la compilación de otro módulo etc. Estos artefactos intermedios se guardarán en Nexus, permitiendo así, que otro desarrollador al compilar no tenga que volver a generarlos y su Maven pueda cogerlos de ahí. Tener gestores de repositorios, son elementos clave para la integración continua. 35

-

En este caso, un gestor de repositorios como Nexus, acelera la compilación de Maven

-

Separación del código (en el control de versiones), de las librerías.

-

Podemos utilizar gestores de repositorios como Nexus o Artifactory para guardar los artefactos finales de nuestra aplicación, para guardar los artefactos que desplegaremos a los diferentes entornos: testing, pre-producción, producción etc.

4.8

Nexus se integran muy bien con servidores de integración continua. Automatización de pruebas y construcción

Los sistemas de prueba y compilación administran las pruebas, el flujo de trabajo y el proceso de compilación que califica y crea versiones. La automatización de pruebas y construcciones automatiza estos procesos eliminando los pasos manuales requeridos. Al igual que con la infraestructura como código, esto entrega para que esas tareas lo manejen a las computadoras. En los días de las primeras computadoras y compiladores, los programas rara vez estaban contenidos en más de un archivo fuente. A medida que los programas comenzaron a crecer en tamaño y complejidad, los desarrolladores comenzaron a dividirlos en múltiples archivos de origen. Las bibliotecas estándar de código puestas a disposición de los usuarios de un lenguaje de programación dado se añaden a la complejidad. Con tantos archivos de origen diferentes que debían compilarse juntos correctamente para obtener los ejecutables finales del programa, se hizo necesario automatizar los procesos de compilación. Las herramientas de automatización de compilación de hoy generalmente especifican cómo se construirá el software (qué pasos deben realizarse y en qué orden) y qué dependencias (qué otro software debe estar presente para que la compilación tenga éxito). Algunas herramientas se adaptan mejor a proyectos en lenguajes de programación específicos, como Maven y Ant de Apache, que, si bien pueden utilizarse técnicamente con otros proyectos, se utilizan con mayor frecuencia en proyectos Java. Otros, como Hudson o Jenkins, se pueden usar más ampliamente con una amplia gama de proyectos. Estas herramientas generalmente caen en uno de los tres casos de uso. La automatización bajo demanda es ejecutada por los usuarios, a menudo en la línea de comandos, a discreción de los usuarios. Por ejemplo, un desarrollador puede ejecutar un script Make a mano durante el desarrollo local para asegurarse de que puede construir el software localmente antes de ingresarlo en el control de versiones. La automatización programada es una automatización que se ejecuta en un calendario predefinido, como una compilación nocturna. Las compilaciones nocturnas se crean todas las noches, generalmente en momentos en que nadie está trabajando, 36

de modo que no se están produciendo nuevos cambios mientras se está desarrollando el software (aunque esto es cada vez menos factible a medida que los equipos se distribuyen de forma más global). Finalmente, la automatización activada ocurre cuando suceden eventos específicos, como un servidor de integración continua que inicia una nueva construcción cada vez que se verifica una confirmación en el código. 4.9

Entrega continua – Continuous Delivery

La entrega continua es el proceso de lanzar software nuevo con frecuencia mediante el uso de integración continua y las pruebas automatizadas. 4.10 Despliegue de aplicaciones El despliegue de aplicaciones es el proceso de planificación, mantenimiento y ejecución en la entrega de una versión de software a los recursos informáticos requeridos. En el sentido general, el arte de la implementación de la aplicación debe considerar el aspecto de los cambios debajo del sistema. La automatización de la infraestructura que construye el cómputo, el sistema operativo y las dependencias necesarias para ejecutar una aplicación específica minimiza el impacto de las inconsistencias que afectan el software. Dependiendo del tipo de aplicación, diferentes preocupaciones de ingeniería pueden ser importantes. Por ejemplo, las bases de datos pueden tener garantías estrictas en términos de consistencia. Si se produce una transacción, debe reflejarse en los datos. El despliegue de aplicaciones es un aspecto crítico para el software de calidad de ingeniería. 4.10.1 Maven Maven es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason van Zyl, de Sonatype, en 2002. Es similar en funcionalidad a Apache Ant pero tiene un modelo de configuración de construcción más simple, basado en un formato XML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya es un proyecto de nivel superior de la Apache Software Foundation. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado. Una característica clave de Maven es que está listo para usar en red. El motor incluido en su núcleo puede dinámicamente descargar complementos de un repositorio, el mismo repositorio 37

que provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores. Este repositorio y su sucesor reorganizado, el repositorio Maven 2, pugnan por ser el mecanismo de facto de distribución de aplicaciones en Java, pero su adopción ha sido muy lenta. Maven provee soporte no solo para obtener archivos de su repositorio, sino también para subir artefactos al repositorio al final de la construcción de la aplicación, dejándola al acceso de todos los usuarios. Una caché local de artefactos actúa como la primera fuente para sincronizar la salida de los proyectos a un sistema local. Maven está construido usando una arquitectura basada en complementos que permite la utilización cualquier aplicación controlable a través de la entrada estándar. En teoría, esto podría permitir a cualquiera escribir complementos para su interfaz con herramientas como compiladores, herramientas de pruebas unitarias, etcétera, para cualquier otro lenguaje. Maven está construido alrededor de la idea de reutilización, y más específicamente, a la reutilización de la lógica de construcción. Como los proyectos generalmente se construyen en patrones similares, una elección lógica podría ser reutilizar los procesos de construcción. La principal idea es no reutilizar el código o funcionalidad, sino simplemente cambiar la configuración o también código escrito. Esa es la principal diferencia entre Apache Ant y Apache Maven: el primero es una librería de utilidades y funciones buenas y útiles, mientras que la otra es un framework configurable y altamente extensible. Aunque Maven es configurable, históricamente el proyecto Maven ha enfatizado seriamente que los usuarios deben adherirse a su concepto de un modelo de proyecto estándar tanto como sea posible. 4.10.1.1 Objetivos de Maven El objetivo principal de Maven es permitir que un desarrollador comprenda el estado completo de un esfuerzo de desarrollo en el menor tiempo posible. Para lograr este objetivo, hay varias áreas de preocupación con las que Maven intenta lidiar: Haciendo el proceso de construcción fácil; Si bien el uso de Maven no elimina la necesidad de conocer los mecanismos subyacentes, Maven proporciona una gran cantidad de protección contra los detalles. Proporcionar un sistema de construcción uniforme; Maven permite que un proyecto se genere utilizando su modelo de objeto de proyecto (POM) y un conjunto de complementos que comparten todos los proyectos que usan Maven, lo que proporciona un sistema de construcción uniforme. Una vez que se familiarice con cómo se construye un proyecto de Maven, automáticamente sabrá 38

cómo se construyen todos los proyectos de Maven, lo que le ahorra una inmensa cantidad de tiempo al tratar de navegar por muchos proyectos. Proporcionar información de calidad del proyecto; Maven proporciona mucha información útil sobre el proyecto que se toma en parte de su POM y en parte se genera a partir de las fuentes de su proyecto. Proporcionar pautas para el desarrollo de mejores prácticas; El objetivo de Maven es reunir principios actuales para el desarrollo de las mejores prácticas y facilitar la orientación de un proyecto en esa dirección. Permitiendo la migración transparente a nuevas funcionalidades; Maven proporciona una forma fácil de actualizar sus instalaciones para que puedan aprovechar los cambios que se hayan realizado en Maven. La instalación de complementos nuevos o actualizados de terceros o de Maven se ha hecho trivial por este motivo. 4.10.1.2 Ciclo de vida proyecto maven Las partes del ciclo de vida principal del proyecto Maven son: compile: Genera los ficheros .class compilando las fuentes .java test: Ejecuta los test automáticos de JUnit existentes, abortando el proceso si alguno de ellos falla. package: Genera el fichero .jar con los .class compilados install: Copia el fichero .jar a un directorio de nuestro ordenador donde maven deja todos los .jar. De esta forma esos .jar pueden utilizarse en otros proyectos maven en el mismo ordenador. deploy: Copia el fichero .jar a un servidor remoto, poniéndolo disponible para cualquier proyecto maven con acceso a ese servidor remoto. Cuando se ejecuta cualquiera de los comandos maven, por ejemplo, si ejecutamos mvn install, maven irá verificando todas las fases del ciclo de vida desde la primera hasta la del comando, ejecutando solo aquellas que no se hayan ejecutado previamente.

39

En la siguiente figura se observa El ciclo de vida predeterminado tiene las siguientes fases de compilación:

Figura 17: Ciclo de vida predeterminado de maven. Fuente: https://www.bogotobogo.com/Java/tutorials/Maven/Apache-Maven-Lifecycle.php

También existen algunas metas que están fuera del ciclo de vida que pueden ser llamadas, pero Maven asume que estas metas no son parte del ciclo de vida por defecto (no tienen que ser siempre realizadas). Estas metas son: clean: Elimina todos los .class y .jar generados. Después de este comando se puede comenzar un compilado desde cero. assembly: Genera un fichero .zip con todo lo necesario para instalar nuestro programa java. Se debe configurar previamente en un fichero XML qué se debe incluir en ese zip. site: Genera un sitio web con la información de nuestro proyecto. Dicha información debe escribirse en el fichero pom.xml y ficheros .apt separados. site-deploy: Sube el sitio web al servidor que hayamos configurado. 4.10.2 Gradle Gradle es un sistema de automatización de construcción de código abierto que construye sobre los conceptos de Apache Ant y Apache Maven e introduce un lenguaje especifico del dominio (DSL) basado en Groovy declarar la configuración de proyecto. Gradle utiliza un grafo acíclico dirigido para determinar el orden en el que las tareas pueden ser ejecutadas.

Gradle fue diseñado para construcciones multi-proyecto las cuales pueden crecer para ser 40

bastante grandes, y da apoyo a construcciones incrementales determinando inteligentemente qué partes del árbol de construcción están actualizadas, de modo que cualquier tarea dependiente a aquellas partes no necesitarán ser re-ejecutada. Los complementos iniciales están principalmente centrados en el desarrollo y despliegue en Java, Groovy y Scala, pero existen más lenguajes y workflows de proyecto en el roadmap. 4.11 Despliegue continuo - Continuous Deployment El despliegue continuo es el proceso de implementación de cambios en la producción a través de la ingeniería de despliegue de aplicaciones que ha definido pruebas y validaciones para minimizar el riesgo. Los cambios de software más rápidos se convierten en producción, las personas más rápidas ven el efecto de su trabajo. La visibilidad del impacto en el trabajo realizado aumenta la satisfacción en el trabajo que conduce a un mayor rendimiento. También conduce a oportunidades para aprender rápidamente. Si algo está fundamentalmente mal con el diseño o la característica, el contexto del trabajo es más reciente y puede ocurrir un cambio. Pasar de la integración continua y la entrega continua al despliegue contínuo es otro paso más hacia la automatización del ciclo de vida del desarrollo del software. Al practicar despliegue continuo, se asegura de que cada cambio sea sólido y lo suficientemente limpio como para que pueda ser lanzado de inmediato a los usuarios (o clientes) sin ninguna intervención manual. Hay diferencia entre Continuous Delivery y Continuous Deployment, la siguiente figura lo muestra:

Figura 18: Continuous Delivery vs Continuous Deployment. Fuente: https://blog.newrelic.com/engineering/continuous-delivery-continuous-deployment-continuous-integration/

41

4.11.1 AWS CodeDeploy AWS CodeDeploy es un servicio de implementación que automatiza las implementaciones de aplicaciones en instancias de Amazon EC2, instancias locales o funciones Lambda serverless. Puede desplegar una variedad casi ilimitada de contenido de aplicaciones, como código, funciones AWS Lambda serverless, archivos web y de configuración, ejecutables, paquetes, scripts, archivos multimedia, etc. También puede desplegar el contenido de la aplicación que se ejecuta en un servidor y se almacena en depósitos de Amazon S3, repositorios GitHub o repositorios Bitbucket. AWS CodeDeploy también puede implementar una función Lambda sin servidor. No es necesario que realice cambios en su código existente antes de poder utilizar AWS CodeDeploy. 4.11.2 Docker Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos. Docker utiliza características de aislamiento de recursos del kernel Linux, tales como cgroups y espacios de nombres (namespaces) para permitir que "contenedores" independientes se ejecuten dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y mantener máquinas virtuales. El soporte del kernel Linux para los espacios de nombres aísla la vista que tiene una aplicación de su entorno operativo, incluyendo árboles de proceso, red, ID de usuario y sistemas de archivos montados, mientras que los cgroups del kernel proporcionan aislamiento de recursos, incluyendo la CPU, la memoria, el bloque de E/S y de la red. De acuerdo con la firma analista de la industria 451 Research, "Docker es una herramienta que puede empaquetar una aplicación y sus dependencias en un contenedor virtual que se puede ejecutar en cualquier servidor Linux. Esto ayuda a permitir la flexibilidad y portabilidad en donde la aplicación se puede ejecutar, ya sea en las instalaciones físicas, la nube pública, nube privada, etc. La figura siguiente muestra el esquema que utiliza Docker para la virtualización.

42

Figura 19: Interfaces virtualización del kernel Linux. Fuente: https://blog.docker.com

Docker implementa una API de alto nivel para proporcionar contenedores livianos que ejecutan procesos de manera aislada. Construido sobre las facilidades proporcionadas por el kernel Linux (principalmente cgroups y namespaces), un contenedor Docker, a diferencia de una máquina virtual, no requiere incluir un sistema operativo independiente. En su lugar, se basa en las funcionalidades del kernel y utiliza el aislamiento de recursos y namespaces separados para aislar la vista de una aplicación del sistema operativo. Docker accede a la virtualización del kernel Linux ya sea directamente a través de la biblioteca libcontainer o indirectamente a través de libvirt, LXC o systemd-nspawn. Mediante el uso de contenedores, los recursos pueden ser aislados, los servicios restringidos, y se otorga a los procesos la capacidad de tener una visión casi completamente privada del sistema operativo con su propio identificador de espacio de proceso, la estructura del sistema de archivos, y las interfaces de red. Contenedores múltiples comparten el mismo núcleo, pero cada contenedor puede ser restringido a utilizar sólo una cantidad definida de recursos como CPU, memoria y E/S. Usando Docker para crear y gestionar contenedores puede simplificar la creación de sistemas altamente distribuidos, permitiendo múltiples aplicaciones, las tareas de los trabajadores y otros 43

procesos para funcionar de forma autónoma en una única máquina física o en varias máquinas virtuales. Esto permite que el despliegue de nodos se realice a medida que se dispone de recursos o cuando se necesiten más nodos, lo que permite una plataforma como servicio (PaaS) de estilo de despliegue y ampliación de los sistemas como Apache Cassandra, MongoDB o Riak. Docker también simplifica la creación y el funcionamiento de las tareas de carga de trabajo o las colas y otros sistemas distribuidos. 4.11.2.1 Integración de Docker con otras herramientas Docker se puede integrar con diferentes herramientas de infraestructura, como Amazon Web Services, Ansible, Cfengine, Chef, Google Cloud Platform, DigitalOcean, IBM Bluemix, Jelastic, Jenkins, Microsoft Azure, OpenStack Nova, OpenSVC, Puppet, SaltStack y Vagrant. 4.11.2.2 Terminología en el argot Docker Algunos términos que se utilizan con frecuencia en el ecosistema Docker. Imágenes: Los planos de nuestra aplicación que forman la base de los contenedores. Contenedores: Creados a partir de imágenes de Docker y ejecutan la aplicación real. Se puede ver una lista de contenedores en ejecución usando el comando docker ps. Docker Daemon: el servicio en segundo plano que se ejecuta en el host que administra la creación, ejecución y distribución de contenedores Docker. El daemon es el proceso que se ejecuta en el sistema operativo con el que los clientes se comunican. Docker Client: la herramienta de línea de comandos que permite al usuario interactuar con el daemon. De manera más general, también puede haber otras formas de clientes, como Kitematic, que proporciona una GUI a los usuarios. Docker Hub - Un registro de imágenes Docker. Puede considerar el registro como un directorio de todas las imágenes de Docker disponibles. Si es necesario, uno puede alojar sus propios registros de Docker y usarlos para extraer imágenes. 4.12 Métricas Las métricas son la colección de mediciones cualitativas y cuantitativas. En general, se comparan con algún estándar de referencia o establecido, se rastrean con fines analíticos o históricos. A menudo las medidas métricas están agrupadas en organizaciones funcionales que pueden impactar en la elección de la dirección correcta del desarrollo del producto. Las métricas son una de las partes clave del monitoreo: los datos se pueden recopilar y almacenar para casi cualquier parte del software web más complejo, y los diferentes equipos pueden tener 44

diferentes métricas que rastrean y utilizan en su trabajo. Statsd y Graphite son de uso muy común y una poderosa combinación para rastrear, almacenar y ver métricas. Existe un esfuerzo impulsado por la comunidad para definir el conjunto de métricas de sistema y aplicación que se deben recopilar agrupadas por protocolo, servicio y aplicación en github en el repositorio de métricas-catálogo. 4.12.1 SonarQube SonarQube es una plataforma de código abierto desarrollada por SonarSource para la inspección continua de la calidad del código para realizar revisiones automáticas con análisis estático del código para detectar errores, vulnerabilidades de seguridad en más de 20 lenguajes de programación. SonarQube ofrece informes sobre códigos duplicados, estándares de codificación, pruebas unitarias, cobertura de códigos, complejidad de código, comentarios, errores y vulnerabilidades de seguridad. SonarQube puede registrar el historial de métricas y proporciona gráficos de evolución. SonarQube proporciona análisis e integración totalmente automatizados con Maven, Ant, Gradle, MSBuild y herramientas de integración continua (Atlassian Bamboo, Jenkins, Hudson, etc.) Se trata de software libre que empleo diversos plugins de análisis estático de código fuente como Checkstyle, PMD o FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del código de un desarrollo software y entender que problemas tenemos en nuestro código fuente.

Figura 20: SonarQube captura de pantalla. Fuente: https://medium.com

Entre sus funciones están la de dar métricas acerca de código duplicado, pruebas unitarias, cobertura del código, potenciales errores o estándares. Inicialmente, la herramienta estaba pensada para Java, pero ahora acepta más de 20 lenguajes. Se integra correctamente con 45

herramientas de integración continua como Jenkins, por lo que se automatizar este análisis cada vez que un desarrollador sube código. Un análisis estático del código no es suficiente, necesitamos también otro tipo de herramientas como los test unitarios para verificar el correcto uso y calidad de nuestro software, pero haciendo un análisis del código sin estar en ejecución podemos detectar elementos como: Problemas de Diseño: Podemos detectar problemas en el diseño y arquitectura del software analizando las dependencias entre las clases del proyecto. Esto nos permite actuar a tiempo frente a crear un enmarañado de clases totalmente acopladas y difícilmente reutilizables. Duplicidad de Código: SonarQube proporciona métricas de código duplicado, pudiendo detectar partes de nuestro software se asemejan, pudiendo así tomar decisiones como desacoplar componentes o aplicar técnicas de refactorización. Detección de Vulnerabilidades: SonarQube cuenta con una base de datos de “code smells” y errores típicos de programación que detectan si alguna línea de código puede estar cometiendo algún problema que pueda vulnerar la seguridad. Por ejemplo, a la hora de cómo recoger los parámetros o cómo usarlos en nuestras consultas para evitar SQL Injection. Standard de codificación: Avisándonos de partes del código que no cumplan con el PSR o incluyan malas prácticas a la hora de definir constantes, variables, llamadas a métodos estáticos. Monitorización de Cobertura: También se puede usar para poder monitorizar si la cobertura de los tests es aceptable y de esta manera tener una visión global del estado de la cobertura de todos los proyectos e invertir en incrementar el volumen de tests del proyecto. 4.13 Logging (Registros) El logging es la generación, filtrado, registro y análisis de eventos que ocurren en un sistema debido al sistema operativo o mensajes de software. Al rastrear el origen de un problema de software, una de las primeras cosas que los ingenieros suelen hacer es verificar los registros para detectar cualquier mensaje de error relevante. Los registros pueden ser tesoros llenos de información útil, y con el almacenamiento cada vez más barato, casi cualquier registro que desee puede guardarse y almacenarse para su uso posterior. Los registros pueden provenir de las aplicaciones que desarrolle, de las herramientas de terceros que utiliza, incluso del sistema operativo. Como no existe una estandarización en el software para el registro, puede ser difícil categorizar y calificar los eventos dentro de los registros para identificar patrones de preocupación. Un solo sistema genera cientos de líneas de registros al día. En entornos modernos que tienen 46

miles de aplicaciones que se ejecutan en cientos o miles de servidores, el gran volumen de datos de registro puede ser abrumador: ya no es una simple cuestión de buscar a través de un archivo de registro. Se ha trabajado mucho en el desarrollo de aplicaciones que manejan el almacenamiento y la búsqueda de registros. 4.13.1 Graylog 2 Este es un sistema de gestión de registro de código abierto totalmente integrado que permite a los administradores del sistema recopilar, indexar y analizar datos tanto enmarcados, sistemáticos y desorganizados de casi todos los sistemas de origen disponibles. Este sistema de registro es altamente conectable y permite la administración centralizada de registros desde muchos sistemas. Se integra con componentes externos como MongoDB para metadatos y ElasticSearch que se usa para mantener los archivos de registro y habilitar la búsqueda de texto. 4.13.1.1 Características Graylog 2 Listo para la producción a nivel empresarial Incluye un tablero de instrumentos y un sistema de alerta. Puede trabajar en datos de cualquier fuente de registro Permite el procesamiento de registro en tiempo real Permite el análisis de datos no estructurados Extensible y altamente personalizable. Ofrece un centro de datos operacional. 4.14 Monitorización(Supervisión) La supervisión es un gran tema que se puede dividir en múltiples facetas de eventos y análisis. Los métodos de recopilación de información incluyen métricas y registros. La supervisión incluye la recopilación de métricas básicas a nivel del sistema, como si un servidor está activo o inactivo, cuánta memoria y CPU se utilizan, y qué tan lleno está cada disco, o podría ser un monitoreo de aplicaciones de mayor nivel que puede variar desde cuántos usuarios solicita el manejo de un servidor web, cuántos elementos se ponen en cola en un sistema de colas, cuánto tarda en cargarse una determinada página web y cuáles son las consultas de más larga ejecución en una base de datos. Si bien una vez solo fue el dominio de los administradores de sistemas y redes, a medida que el software se vuelve más complejo y los equipos colaboran más, las personas 47

comienzan a darse cuenta de que es un reflejo central de la salud del producto. Uno de los beneficios de usar la administración de la configuración es que se puede usar para ayudar a automatizar el proceso de configuración del monitoreo de nuevos sistemas o servicios. El monitoreo solo funciona cuando está configurado para monitorear las cosas correctas - no quiere darse cuenta solo después de que se haya producido un incidente, eso quiere decir que el monitoreo aún no se ha configurado correctamente. Una vez que haya determinado lo que necesita monitorear, la gestión de la configuración se puede usar para monitorear automáticamente los nuevos hosts o servicios a medida que se implementan o aprovisionan. Además, muchos sistemas de gestión de la configuración tienen un monitoreo incorporado, como, por ejemplo; cuándo se registró cada host, para obtener una confianza adicional de que los sistemas están configurados como se espera. En el entorno de hoy, con más y más sistemas conectados a la Internet y la mayor visibilidad que se produce con los incidentes que son altamente publicitados, las empresas están empezando a preocuparse cada vez más por la seguridad. Diremos que además de controlar el estado de sus sistemas y aplicaciones, también se debe considerar la supervisión de la seguridad de su entorno. Esto podría significar cualquier cosa, desde los números de seguimiento de los intentos fallidos de inicio de sesión hasta la configuración de un sofisticado sistema de detección de intrusos, pero en cualquier caso no es algo que deba olvidarse o dejarse hasta el último minuto. En general, la supervisión es el proceso de seguimiento del estado actual de sus sistemas y entorno, generalmente con el objetivo de verificar si cumplen o no algunas condiciones predefinidas de cuál es el estado deseado. A menudo, el monitoreo, las alertas y las pruebas se combinan. Esto lleva a la confusión en torno a la comprensión de lo que estamos tratando de lograr o construir. Como se mencionó anteriormente, el monitoreo generalmente se ejecuta en un horario predefinido, mientras que las pruebas se ejecutan en respuesta a los cambios. Las alertas son comunicaciones automáticas enviadas a personas sobre los resultados de una prueba o un monitor. 4.15 Alertas La supervisión y las alertas son importantes no solo desde la perspectiva del rendimiento, sino también como una forma de asegurar de que se conocerá de posibles problemas antes de que se conviertan en problemas reales. Al razonar sobre las alertas, hay varios factores que deben considerarse: Impacto: no todos los sistemas tienen el mismo impacto; algo que está muy extendido y afecta a 48

múltiples sistemas o a un gran grupo de clientes, tiene un impacto mucho mayor que algo que afecta solo a un pequeño subconjunto de sistemas o personas. Urgencia: Similar al impacto, no todos los problemas son igualmente urgentes. Un problema urgente es uno que requiere una respuesta rápida (o a veces inmediata). Parte interesada: Principalmente, las partes interesadas en un incidente son las afectadas, pueden ser sus clientes (o un subconjunto de ellos) o grupos de empleados en el caso de incidentes de servicio interno. Las partes interesadas también podrían interpretarse como quién es responsable de responder a un incidente. Recursos: Los recursos que se requieren para responder a un incidente o alerta dado, y cuál es la disponibilidad de esos recursos. ¿Hay suficiente cobertura humana para asegurarnos de que se puedan responder múltiples incidentes, o tiene solo una persona de guardia que es un punto único de falla sin respaldo? ¿Tiene su organización los recursos para funcionar sin un servicio dado, pieza de hardware o individuo? Estas son todas las cosas que se deben tener en cuenta al configurar sus alertas. Costo: existe un costo asociado con el monitoreo y las alertas, desde el costo de un servicio y solución de monitoreo, el espacio de almacenamiento para el monitoreo histórico o los datos de alerta, hasta el costo de enviar alertas a personas, por no mencionar los costos asociados con la respuesta a incidentes desde el punto de vista de la persona que maneja el problema hasta el costo para su compañía si un servicio determinado no está disponible. 4.16 Gestión Eventos La gestión de eventos es el elemento de monitoreo que se ocupa del conocimiento existente sobre los impactos en los sistemas y servicios. Para los servicios 24x7, esto generalmente refleja la necesidad de información en tiempo real sobre el estado de todos los diferentes componentes de la infraestructura. Un sistema está configurado para monitorear una métrica o registro específico en función de un evento definido y una señal o alerta si se cruza un umbral o si se cumple una condición de alerta. Ahora que se está realizando mucho desarrollo de software en el software web que se espera que esté disponible las 24 horas del día, los 7 días de la semana, se está prestando más atención al manejo de las alertas que se producen cuando los ingenieros están en casa en lugar de en la oficina. Una forma de lidiar con esto es configurar la mayor cantidad posible de manejo automatizado de eventos.

49

Muchos sistemas de alerta y monitoreo tienen formas integradas de responder automáticamente a un evento determinado. El sistema de monitoreo de Nagios, por ejemplo, tiene "controladores de eventos" que pueden configurarse para diferentes condiciones de alerta. Estos manejadores pueden hacer una variedad de cosas, desde reiniciar automáticamente un servicio que se ha estrellado hasta crear un ticket para que un técnico reemplace un disco duro defectuoso. Los manejadores de eventos automatizados pueden reducir la cantidad de trabajo que el personal de operaciones tiene que hacer (y probablemente la cantidad de veces que se despiertan fuera de horario) pero no están exentos de riesgos. Es importante asegurarse de que sus condiciones de falla estén claramente definidas, que el proceso del manejador de eventos se entienda lo suficientemente bien como para ser automatizado y que existan las medidas de seguridad necesarias para evitar que la automatización cause más problemas de los que resuelve. Ningún sistema de alerta es 100% exacto el 100% del tiempo. Un evento falso positivo es cuando se generó un evento cuando en realidad no hubo un problema. Si sus eventos generan alertas, como páginas que están diseñadas para despertar a las personas durante las horas de descanso para tratarlas, un falso positivo perturbará el sueño de alguien innecesariamente. Por otro lado, un falso negativo es cuando ocurrió un incidente sin generar un evento para él, lo que podría llevar a un período más largo antes de que se detectara y resolviera el problema. Hay costos tanto para los falsos positivos como para los falsos negativos, y cuál de los riesgos es mejor o peor, dependerá de sus problemas y entorno específicos. Con el tiempo, deseará ajustar y ajustar su monitoreo y alerta a medida que aprende más sobre el verdadero impacto de sus problemas y eventos. Recomendamos monitorear las tendencias de sus alertas, incluida información como si se tomó o no alguna acción para cada evento, cuántas de sus alertas fueron accionables en general y cuántas de ellas ocurrieron fuera de las horas. Los entornos cambian, algo que era un problema antes puede no serlo ahora debido a un cambio en la función del software o la complejidad aumenta y la vieja forma de resolver el problema ya no funciona. Los humanos pueden cambiar para resolver el problema rápidamente, los algoritmos no tienen los mismos comportamientos adaptativos. Hacer frente a este cambio constante es una parte importante de la gestión de alertas e incidentes.

50

5

Conclusiones

La naturaleza del trabajo del DevOps varía de una organización a otra. En algunos casos, su función es la automatización de la infraestructura y su mantenimiento. Mientras que algunas organizaciones abarcan su papel en toda la cadena de distribución. El DevOps tiene que colaborar con personal de desarrollo y despliegue para superar la barrera de colaboración tradicional. Diferentes organizaciones tienen diferentes barreras. Aunque el rol del ingeniero de DevOps puede variar, se identificó dos cosas que casi todos los ingenieros de DevOps tocarán a diario: la automatización y la integración continua. De la misma manera se concluye que las herramientas van muy de la mano a los roles que desempeña el ingeniero DevOps. Automatización La mayoría de las tareas relacionadas con el mantenimiento de la infraestructura son todavía manuales. Las empresas prefieren utilizar metodologías probadas tradicionales en lugar de automatizar el mismo proceso, ya que no quieren correr ningún riesgo. Pero el hecho es que las tareas automatizadas ayudarán a un desarrollo y una implementación más rápidos del software. Para este punto considere, por ejemplo, si a un ingeniero de sistemas se le ha asignado la tarea de hacer una copia de seguridad de todos los servidores dos veces al día de forma manual, perderá el tiempo haciendo esto ya que podría haberse logrado fácilmente escribiendo un script para hacer una copia de seguridad automática de su servidor en alguna infraestructura de la nube. Al automatizar el proceso de copia de seguridad, permite que su ingeniero de sistemas se centre más en aspectos críticos, como la solución de problemas de los servidores que no funcionan debido a algún problema de VM. Hacer lo mismo manualmente resultará en una sobrecarga para su ingeniero de sistemas cuya eficiencia se reducirá drásticamente. Este es solo un ejemplo muy simple para elaborar el concepto de desperdicio de recursos al no pasar a la automatización. DevOps reduce los riesgos que pueden surgir debido a la falta de colaboración entre los desarrolladores, el control de calidad y el equipo de implementación. Pero también reconoce el hecho de que el desarrollo de software de alta calidad requiere un compromiso continuo y retroalimentación de todas las partes interesadas, incluidos los especialistas en control de calidad y operaciones. Los ingenieros de DevOps pueden automatizar el proceso de configuración de servidores mediante la creación de un entorno de scripting. Puede ejecutar scripts en un nodo, pero no será 51

práctico ejecutar el mismo script en cientos de nodos. Scripting no es una solución escalable aquí. Por lo tanto, existe la necesidad de automatizar el aprovisionamiento de software, la administración de la configuración y el despliegue de aplicaciones en una gran cantidad de nodos de manera escalable. Aquí es donde las herramientas de administración de la configuración, como Chef, Puppet y Ansible, son muy importantes. Integración continua Otro aspecto importante acerca de DevOps es la integración continua – continuous integration (CI) permite a los desarrolladores actualizar continuamente los cambios del repositorio, desde donde se realizan las compilaciones y las pruebas automatizadas. Un sistema de integración continua involucra una herramienta que supervisa el sistema de control de versiones. Siempre que se detecte un cambio en el sistema de control de versiones, el sistema construirá y probará automáticamente su aplicación. Si la compilación o prueba falla, el sistema notifica de inmediato a los desarrolladores para que solucionen el problema de inmediato. Con la integración continua, los desarrolladores pueden mejorar su productividad a medida que se liberan de las tareas manuales, que ahora se realizan de manera automatizada en CI; Los errores son más fáciles de encontrar y mitigar como resultado de las pruebas frecuentes; Las actualizaciones para el usuario final se pueden entregar de forma rápida y más frecuente. Jenkins permite alojar los servidores de CI en su propia infraestructura de red, así como también otros productos de CI alojados completamente alojados en la nube. El rol más crítico que desempeñan los ingenieros de DevOps es cerrar la brecha entre el desarrollo de software y los equipos de operaciones para aumentar la tasa de entrega de software. El rol del ingeniero de DevOps varía según el contexto de las organizaciones, pero hay dos aspectos comunes y esos son la automatización y la integración continua.

52

6

Bibliografía

AWS.

(s.f.).

AWS

CodeDeploy.

Obtenido

de

AWS

Amazon:

https://aws.amazon.com/es/codedeploy/ Berg, A. M. (2012). Jenkins Continuous - Integration Cookbook (1st ed.). Birmingham: Packt Publishing Ltd. CFEngine.

(s.f.).

How

does

CFEngine

works?

Obtenido

de

CFEngine:

https://cfengine.com/learn/how-cfengine-works/ Chef. (s.f.). Chef Docs. Obtenido de Learn Chef: https://docs.chef.io/ Coté. (2016). Roles and Responsibilities for DevOps and Agile Teams. Medium. Obtenido de https://medium.com/@cote/roles-and-responsibilities-for-devops-and-agile-teamsfdacbffb4cb4 Daniels, J. D. (2016). Effective DevOps - Building a Culture of Collaboration, Affinity, and Tooling at Scale. 1005 Gravenstein Highway North, Sebastopol, CA: O’Reilly Media, Inc. Docker. (s.f.). Build, Manage and Secure Your Apps Anywhere. Your Way. Obtenido de Enterprise Container Platform.: https://www.docker.com/ Enterprise, G. (s.f.). Gradle Buid Tool. Obtenido de Gradle Buid Tool: https://gradle.org Fernández, J. P. (2015). DevOps y el camino de baldosas amarillas. Joapen Projects. Obtenido de http://joapen.com/blog/2015/10/26/devops-y-el-camino-de-baldosas-amarillas/ Foundation, A. (s.f.). Apache Maven Project. Obtenido de Apache Maven Project: https://maven.apache.org/ Gene Kim, J. H. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Portland, OR. USA: IT Revolution Press. Hüttermann, M. (2012). DevOps for Developers. 233 Spring Street, 6th Floor, New York, NY 10013. USA: Apress. Jenkins. (s.f.). Jenkins User Documentation. Obtenido de Jenkins: https://jenkins.io/doc/ Mouat, A. (2016). Using Docker. Sebastopol, CA.: O’Reilly Media, Inc. Overby, S. (2015). 7 DevOps roles you need to succeed. TechBeacon. Obtenido de https://techbeacon.com/7-devops-roles-you-need-succeed Puppet. (5 de November de 2018). Puppet. Obtenido de Puppet: https://puppet.com/ 53

Ramiro, R. (2017). Las mejores herramientas y recursos DevSecOps. ciberseguridad.blog. Obtenido de https://ciberseguridad.blog/las-mejores-herramientas-y-recursos-devsecops/ Red Hat, A. (5 de November de 2018). Ansible. Obtenido de Ansible is simple IT Automation: https://www.ansible.com/ Reed, J. P. (2015). DevOps in Practice. 1005 Gravenstein Highway North, Sebastopol, CA: O’Reilly Media, Inc. Scott Chacon, B. S. (2014). Pro Git (2nd ed.). San Francisco, California: APress. SonarSource.

(s.f.).

SonarQube.

Obtenido

de

Continuous

Inspection

|

Sonar:

https://www.sonarqube.org/ Stackify. (2017). Top DevOps Tools: 50 Reliable, Secure, and Proven Tools for All Your DevOps Needs. Stackify. Obtenido de https://stackify.com/top-devops-tools/ Talari, S. (2018). Important DevOps Roles Every Organization Needs to Succeed. DevOps.com. Obtenido

de

https://devops.com/important-devops-roles-every-organization-needs-to-

succeed/ Vagrant. (s.f.). Vagrant by Hashi Corp. Obtenido de Vagrant: https://www.vagrantup.com/ Watts, S. (2017). DevOps Engineer Roles and Responsibilities. BMC. Obtenido de https://www.bmc.com/blogs/devops-engineer-roles-and-responsibilities/ Wikipedia. (2018). DevOps. Wikipedia. Obtenido de https://es.wikipedia.org/wiki/DevOps Yasar, H. (2018). Roles and Responsibilities on DevOps Adoption. (pág. 27). Pittsburgh, PU: Carnegie Mellon University.

54