DevOps para principiantes

8-8-2015

DevOps para principiantes Manual de implementación

Yadder Aceituno Gonzalez 201021209

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERIA

Tabla de contenido Qué es DevOps? .......................................................................................................................... 2 1.

DevOps no es un puesto de trabajo .............................................................................. 3

2.

DevOps no se trata de resolver un problema de TI ..................................................... 3

3.

DevOps no es un sinónimo de integración continua .................................................. 3

4.

DevOps está aquí para quedarse .................................................................................. 4

Los Principios de DevOps ............................................................................................................ 5 1.

Desarrollar y probar contra sistemas que emulan los de producción ...................... 6

2.

Desplegar bajo procesos confiables y repetibles ........................................................ 6

3.

Monitorear y validar la calidad operacional ................................................................ 6

4.

Ampliar círculos de retroalimentación ........................................................................... 7

Gestion de Versionamiento ........................................................................................................ 8 1.

El repositorio ....................................................................................................................... 9

2.

Modelos de versionado .................................................................................................... 9 El problema de compartir archivos .................................................................................. 10 La solución bloquear-modificar-desbloquear ................................................................ 10 La solución copiar-modificar-fusionar.............................................................................. 11

Integración Continua ................................................................................................................ 12 1.

Las buenas prácticas ...................................................................................................... 13 Práctica de desarrollo de software .................................................................................. 13 Los miembros del equipo integran su trabajo frecuentemente .................................. 13

2.

Los pasos para implementar integración continua ................................................... 14

2.1

Conciencia a las personas y da información sobre el tema ................................ 14

2.2

Tener claro el proceso de desarrollo de la empresa ............................................. 14

2.3

Tener clara la política de gestión y control de versiones ...................................... 15

2.4

Gestión de tareas y trazabilidad ............................................................................... 15

2.5

Automatización del build ........................................................................................... 15

2.6

Definir cual va a ser el pipeline de integración continua ..................................... 16

2.7

Elegir e instalar el servidor de integración continua .............................................. 16

2.8

Automatizar pruebas................................................................................................... 16

2.9

Inspección continua ................................................................................................... 17

2.10

Implementar entrega continua y despliegue continuo ........................................ 17



DevOps para principiantes Capítulo 1

Qué es DevOps? Mucho se ha escrito acerca de lo que es DevOps: Un camino para que los desarrolladores y directores de operaciones colaboren; un conjunto de mejores prácticas para la gestión de aplicaciones en la nube; una idea ágil que se basa en la integración continua, lo que permite frecuentes liberaciones de código. La definición de DevOps cubre todas estas cosas y más. Pero dado que el término ha adquirido estatus de palabra de moda, puede ser más interesante preguntarse no lo que es DevOps, sino lo que no es. En el artículo SearchSoftwareQuality preguntó a algunos profesionales de software exactamente eso. He aquí lo que dijeron.



1. DevOps no es un puesto de trabajo Publicaciones en sitios de empleo sugieren otra cosa, pero DevOps no es un puesto de trabajo, dijo el consultor de Agile, Scott Ambler. "¿Gestor de DevOps? No sé lo que es eso". DevOps no debe ser un rol laboral, dijo. "DevOps se trata de que los desarrolladores entiendan la realidad de las operaciones y de que el equipo de operaciones comprenda lo que involucra el desarrollo”. DevOps, el concepto, es un aspecto importante del desarrollo y la entrega de software, dijo Ambler. "Pero el puesto de DevOps es un síntoma de que las organizaciones que contratan no entienden lo que DevOps es realmente. Ellos no lo entienden todavía." La postura de Ambler sobre DevOps va en contra de la sabiduría convencional. DevOps apareció en la lista de 10 títulos de trabajo que es probable encontrar, de acuerdo con SearchCIO.com.

2. DevOps no se trata de resolver un problema de TI A pesar de sus muchos significados, DevOps es ampliamente entendido como una forma de resolver un problema de TI: permite que el área de desarrollo y operaciones colaboren en la entrega de software. Pero ese no es su objetivo final, dijo Damon Edwards, socio gerente de consultoría de TI, Soluciones DTO. "El punto de DevOps es permitirle a su empresa reaccionar ante las fuerzas del mercado lo más rápido, eficiente y confiable como sea posible. Sin el negocio, no hay otra razón para que estemos hablando de problemas DevOps, mucho menos pasar tiempo resolviéndolos". Kevin Parker, experto de SearchSoftwareQuality, dijo que el nuevo reto que encaran los gerentes de DevOps es toda la atención que el tema obtiene por parte del negocio. "Lo que antes era una tarea arcana, de elaborada coordinación y gestión de proyectos es ahora en parte diplomacia, parte protector y una buena cantidad de innovación."

3. DevOps no es un sinónimo de integración continua DevOps se originó en Agile como una forma de apoyar la práctica ágil de liberaciones de código más frecuentes. Pero DevOps es más que eso, dijo Ambler. "El hecho de que se practique la integración continua no significa que se está haciendo DevOps." Él ve a los gerentes de operaciones como los principales interesados que los equipos ágiles necesitan trabajar para liberar software.



4. DevOps está aquí para quedarse En el dinámico mundo de la tecnología, el empleo evoluciona en respuesta a las nuevas necesidades. A medida que cambian los requisitos, la demanda de estos nuevos puestos de trabajo aumenta. Una rama de desarrollo Agile, DevOps desdibuja las líneas entre los desarrolladores y equipos de operaciones mediante el fomento de los desarrolladores a tener una comprensión de los principios de las operaciones, y alentar a los profesionales de operaciones para reforzar sus habilidades de codificación y automatización. Como cada vez más empresas mueven los datos hacia la Nube y necesitan múltiples centros de datos de todo el mundo, los roles estratégicos son necesarios, y ahí es donde el papel DevOps encuentra su nicho. El rol de DevOps apela a las empresas, pues está diseñado para lograr más con menos. El punto de derribar los silos de TI tradicionales es aumentar la comunicación entre los empleados. "Hay que abrir líneas directas de comunicación", dijo Robert Stinnett, Ingeniero de Automatización del Centro de Datos de Columbia, Missouri. Stinnett, sin embargo, tuvo unas palabras de advertencia para aquellos interesados en contratar a personal de desarrollo en DevOps. "Las empresas no deben usar DevOps como una excusa para tener gente haciendo dos o tres trabajos diferentes", dijo. "Si usted lo está haciendo para ahorrar dinero, usted va a fracasar."




Los Principios de DevOps DevOps no es solo una palabra nueva en nuestro vocabulario, sino también una nueva forma de hacer negocios. El nombre "DevOps" (una combinación de las palabras "desarrollo" y “operaciones") aún no está en el diccionario Webster. Sin embargo, se está convirtiendo rápidamente en un esfuerzo popular para la gestión y el uso común de los administradores de TI en la industria del software. Entender los principios de DevOps aporta valor a la empresa quien las aplica así como a aquellos que utilizan lo que despliegan. He aquí algunos de los principios que presenta esta filosofía.



1. Desarrollar y probar contra sistemas que emulan los de producción El objetivo aquí es permitir que los equipos de desarrollo y de aseguramiento de la calidad desarrollen y prueben contra sistemas que se comportan tal como lo hace el sistema en su fase de producción. De esta manera se puede observar cómo se comporta la aplicación y también su desempeño, mucho antes de que esté lista para su despliegue. Se busca probar la aplicación bajo el ambiente más parecido al real y simultáneamente también se busca validar los procesos de entrega de aplicaciones. Desde el punto de vista de operaciones este principio tiene un enorme valor, ya que permite ver muy temprano en el ciclo cómo se comporta el ambiente que debe soportar la aplicación y permite eventualmente crear las bases para poder entonar ese ambiente en función de la aplicación.

2. Desplegar bajo procesos confiables y repetibles Este principio permite a desarrollo y operaciones apoyar un proceso de desarrollo ágil e iterativo en todas las fases hasta producción. La automatización es esencial para poder crear procesos que cumplan con las siguientes condiciones: iterativos, frecuentes, repetibles y confiables. Esto le permite a la organización crear una cartera de entregables, donde los despliegues y las pruebas se pueden realizar en forma automática y continua. La ejecución frecuente de despliegues también permite poner a prueba los procesos de despliegue, limitando los riesgos de fallas en los momentos de entrega.

3. Monitorear y validar la calidad operacional Típicamente las organizaciones son muy buenas monitoreando aplicaciones y sistemas en producción, ya que existen muchas opciones para hacer esto y ellas utilizan herramientas que permiten capturar las métricas de producción en tiempo real. Sin embargo, este monitoreo es realizado sobre aplicaciones individuales, donde las aplicaciones no están conectadas las unas con las otras. DevOps exige que el monitoreo sea realizado más temprano en el ciclo, requiriendo además que se haga monitoreo de las características funcionales y de las características nofuncionales de la aplicación.



En cualquier momento, a medida que las aplicaciones están siendo desplegadas y probadas, DevOps exige que se capturen métricas de calidad y que sean analizadas. Este monitoreo frecuente provee aviso tempranero sobre temas operacionales y de calidad que podrían aparecer posteriormente en la etapa de producción. Adicionalmente, las métricas deben ser capturadas en un formato que sea entendible y utilizable para todos los interesados, incluyendo a los responsables de las aplicaciones en las líneas de negocio.

4. Ampliar círculos de retroalimentación Uno de los principales objetivos de DevOps es permitir a las organizaciones reaccionar y poder realizar cambios rápidamente en sus procesos de negocio. En la entrega de software, el objetivo se transforma en proveer retroalimentación en un corto tiempo y además poder aprender rápidamente de cada acción que se toma. Las organizaciones deben crear canales de comunicación que permitan a todas las partes interesadas accesar a la información y actuar sobre la base de la retroalimentación y por ello: 

Desarrollo puede actuar ajustando sus planes de proyecto o sus prioridades.



Producción (Operaciones) puede actuar mejorando los ambientes de producción.



Las Líneas de Negocios pueden actuar modificando sus planes de implementación.




Gestion de Versionamiento La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción. La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.



1. El repositorio Un gestor de versionamiento es un sistema centralizado para compartir información. En su núcleo está un repositorio, que es un almacén central de datos. El repositorio almacena información en forma de un árbol de archivos (una jerarquía típica de archivos y directorios). Un número de clientes se conectan al repositorio, y luego leen o escriben esos archivos. Al escribir datos, el cliente hace que la información esté disponible para los otros; al leer los datos, el cliente recibe información de los demás.

Figura 1

Cuando un cliente lee datos de un repositorio, normalmente ve únicamente la última versión del árbol de archivos. Pero el cliente también tiene la capacidad de ver estados previos del sistema de archivos. Por ejemplo, un cliente puede hacer preguntas históricas, como “¿qué contenía este directorio el último miércoles?”, o “¿quién fue la última persona que cambió este archivo, y qué cambios hizo?” Esta es la clase de preguntas que forman el corazón de cualquier sistema de control de versiones: son sistemas que están diseñados para guardar y registrar los cambios a los datos a lo largo del tiempo.

2. Modelos de versionado Todos los sistemas de control de versiones tienen que resolver los mismos problemas fundamentales: ¿cómo permitirá el sistema compartir información entre usuarios, pero evitando que ellos accidentalmente se pisen unos a otros? Es demasiado sencillo que los usuarios accidentalmente sobre-escriban los cambios del otro en el repositorio.



El problema de compartir archivos

Considere este escenario: suponga que tiene dos compañeros de trabajo, Harry y Sally. Cada uno decide editar el mismo archivo del repositorio a la vez. Si Harry graba sus cambios en el repositorio primero, el posible que (unos momentos

después)

accidentalmente

Sally

sobre-escribirlos

pueda con

su

propia versión nueva del archivo. Mientras que la versión del archivo de Harry no se ha perdido para siempre (porque el sistema recuerda cada cambio), cualquier cambio que Harry hizo no estará en la versión nueva del archivo de Sally, porque para empezar ella nunca vio los cambios de Harry. El trabajo de Harry está aun efectivamente perdido (o al menos falta en la última versión del archivo) y probablemente por accidente. ¡Esta es una situación que definitivamente tenemos que evitar! La solución bloquear-modificar-desbloquear

Muchos sistemas de control de versiones utilizan

un

modelo bloquear-modificar-

desbloquear para enfrentarse al problema, lo cual es una solución muy simple. En estos sistemas, el repositorio sólo permite que una persona cambie un archivo. Harry primero debe bloquear el archivo antes que pueda empezar a hacer cambios en él. Bloquear un archivo se parece mucho a tomar prestado un libro de la biblioteca; si Harry ha bloqueado un archivo, entonces Sally no puede hacer ningún cambio en él. Si ella intenta bloquear el archivo, el repositorio le denegará la petición. Todo lo que ella puede hacer es leer el archivo, y esperar a que Harry termine sus cambios y libere su bloqueo. Después que Harry desbloquee el archivo, se acabó su turno, y ahora es el turno de Sally para bloquear y editar.



La solución copiar-modificar-fusionar

La mayoría de gestores de versiones utilizan este modelo. En este modelo, el cliente de cada usuario lee el repositorio y crea una copia de trabajo personal del archivo o del proyecto. Luego, los usuarios trabajan en paralelo, modificando sus copias privadas. Finalmente, las copias privadas se fusionan juntas en una nueva versión final. El sistema de control de versiones a menudo ofrece ayuda en la fusión, pero al final la persona es la responsable de hacer que ocurra correctamente. Aquí hay un ejemplo. Digamos que tanto Harry como Sally crean copias de trabajo del mismo proyecto, copiado del repositorio. Ellos trabajan simultáneamente, y hacen cambios al mismo archivo A dentro de sus copias. Sally es la primera en grabar sus cambios en el repositorio. Cuando Harry intenta grabar sus cambios más tarde, el repositorio le informa que su archivo A está desactualizado. En otras palabras, que el archivo A en el repositorio ha cambiado de alguna forma desde la última vez que lo copió. Por lo que Harry le pide a su cliente que fusione cualquier nuevo cambio del repositorio dentro de su copia de trabajo del archivo A. Lo más seguro es que los cambios de Sally no se superpongan a los suyos; por lo que una vez que ambos conjuntos de cambios se han integrado, él graba su copia de trabajo de nuevo en el repositorio.




Integración Continua Muchas veces, se tiende a pensar que la integración continua es tener instalado el servidor de integración continua (por ejemplo Jenkins) y que este compile el código periódicamente; o tener automatizados los despliegues dándole a un botón desde dicho servidor. Pero la integración continua engloba mucho más que esto. Es una serie de buenas prácticas, de comprobaciones interconectadas entre sí, para conseguir software de mejor calidad. Martin Fowler define la integración continua de la siguiente manera: “Práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente, al menos una vez al día. Cada integración se verifica con un build automático (que incluye la ejecución de pruebas) para detectar errores de integración tan pronto como sea posible.”



1. Las buenas prácticas Partiendo de la definición de Fowler, poder identificar a los componentes e ideas claves de las buenas prácticas de integración continua.

Práctica de desarrollo de software

Para implantar integración continua solemos definir un “pipeline”, un conjunto de etapas, de fases por las que va pasando el software y que se automatizan. Un ejemplo de un pipeline podría ser que con cada subida de código al repositorio de control de versiones este se descargue y compile. Si está todo correcto, que se ejecuten una serie de pruebas unitarias, o se despliegue el código a otro entorno para hacer pruebas de sistema. Por último, que se despliegue al entorno de QA, de pruebas, para realizar otro tipo de pruebas manuales. Esta es una de las primeras cosas que hay que definir, saber cómo es el desarrollo, cuál es el criterio para que el código promocione de un entorno a otro, y qué se hace en cada entorno. Y si el código no pasa algún punto hay que establecer cuál es la estrategia para resolver el error, quién se encarga de ello, cómo se gestiona.

Los miembros del equipo integran su trabajo frecuentemente

Cuando se distribuye el trabajo entre los miembros del equipo, y cada uno comienza a trabajar, normalmente se asumen cosas de otros componentes del software que todavía no están implementados o que está programando otra persona. Y hasta que no se junta todo ese código, no son visibles los errores de integración que se cometen. Antes, lo que se tendía a hacer es que cada desarrollador programara de forma independiente y luego al final se realizaba la integración de todo el código. Esto se traduce en integraciones difíciles, que tardan mucho en completarse y mucho sufrimiento, ya que hay muchos cambios, mucho código que integrar. Uno de los motivos por los que surge la integración continua es para evitar esto. La idea es que en vez de dejar la integración para el final, se vayan haciendo pequeñas integraciones de código frecuentemente. La frase que podríamos aplicar aquí es que si algo te cuesta, debes hacerlo más a menudo y poco a poco, para que con el tiempo te vaya costando cada vez menos esfuerzo.



2. Los pasos para implementar integración continua Implementar integración continua conlleva un cambio en la forma de trabajo del equipo, en el día a día de las personas, que debe ir siendo aceptado poco a poco. Aquí enumeramos los pasos principales para implementar la integración continua, y unos pequeños consejos, puesto que deberás adaptar los pasos a tu empresa, al software etc.

2.1 Conciencia a las personas y da información sobre el tema Los cambios afectan a las personas, y normalmente, tendemos a no querer cambiar, a aceptar lo malo aunque sea conocido frente al cambio. Hay que facilitar el cambio, explicando ante todo qué se va a hacer, y por qué se va a implantar integración continua. Incluso, podría ser un buen momento para hablar con el equipo y que ellos mismos dijeran qué cosas negativas o positivas ven al proceso de desarrollo actual, o cómo lo mejorarían. Además, es importante ir formando al equipo en las nuevas tecnologías que vayas a implantar, en hacer pruebas unitarias, de integración, en buenas prácticas, patrones de diseño, etc.

2.2 Tener claro el proceso de desarrollo de la empresa Con esto me refiero a por ejemplo, tener bien definido cosas como qué entornos hay (por ejemplo, desarrollo, testing, pre-producción y producción), cuáles son los criterios para que las versiones software pasen de un entorno a otro, qué se hace en cada entorno, qué tipos de pruebas se hacen y en qué momento etc. Un servidor de integración continua como Jenkins va a ser un elemento de enlace para todo esto. Es decir, vamos a intentar mejorar el desarrollo, introduciendo más comprobaciones, pero también vamos a intentar automatizar todos los procesos repetibles, manuales que se puedan

automatizar para invertir tiempo en otras cosas. Por ejemplo, podríamos programar el servidor de integración continua para que cuando el código que alguien suba al control de versiones se compile y pase ciertas pruebas, se despliegue automáticamente y promocione a otro entorno.



2.3 Tener clara la política de gestión y control de versiones Sin control de versiones, la integración continua no funciona. El servidor de integración continua vigila, monitoriza los cambios que se hagan en el sistema de control de versiones. Por ello, antes de ponernos manos a la obra implantando integración continua es necesario pensar cómo vamos a combinar nuestra estrategia de control de versiones con la integración continua. Por ejemplo, ten en cuenta que para decidir la estrategia de control de versiones a seguir (sobre todo el tema de crear ramas o no) también influirá qué herramienta de control de versiones utilizáis en la empresa.

Subversion o SVN, no son iguales que Git o Mercurial y no gestionan las ramas de la misma manera. Con Git o Mercurial, una estrategia de rama por historia de usuario es mucho más fácil y eso es algo a tener en cuenta.

2.4 Gestión de tareas y trazabilidad Algo muy útil para controlar los pequeños trozos de código que se agregan al repositorio esto son las herramientas de gestión de tareas, como Jira o Redmine. Y otra cosa importante es conseguir trazabilidad entre las tareas o requisitos, y el código, el cuál es el commit (la modificación) del control de versiones en el que dicho requisito se ha implementado. Esto es indispensable siempre, pero muy útil cuando detectemos fallos en el código. Así tendremos controlado en qué commit del código se ha dado el fallo y que hay implementado y que no.

2.5 Automatización del build Para automatizar el build (compilación), puedes emplear scripts, herramientas como Ant o Maven. Otro consejo es que intentes que la compilación no tarde demasiado. Ve optimizando el proceso de compilación a lo largo del tiempo. La compilación es el primer paso dentro de la integración continua, antes de ejecutar pruebas, por lo que si en ese punto tardamos mucho tiempo, todo el proceso se demorará mucho y no conseguiremos feedback rápido sobre qué falla en la aplicación.



2.6 Definir cual va a ser el pipeline de integración continua Se debe pensar qué pasos, o por qué fases deberá ir pasando el código. Define un pipeline de integración continua (una serie de fases, pasos), que luego se programara en el servidor de integración continua. En este caso distinguiría entre las pruebas básicas que deben pasarse cada vez que se hace una subida al control de versiones, un smoke test para dar feedback rápido al desarrollador de si las cosas están medianamente bien y otra serie de pasos más avanzados con pruebas más a fondo (Smoke test: Detecta lo más pronto posible si los elementos críticos de la aplicación no funcionan.).

2.7 Elegir e instalar el servidor de integración continua Una vez hecho todos los puntos anteriores pasaríamos a instalar y configurar el servidor de integración continua. Además de implementar el pipeline que hemos definido previamente. Si por ejemplo usas Jenkins como servidor de integración continua, y en el paso anterior pensaste las distintas fases, etapas por las que va pasando el software, te será muy sencillo configurar el pipeline en Jenkins. Cada etapa o fase puede ser una tarea (job) de Jenkins, que ejecutará la siguiente fase en caso de que todo sea un éxito.

2.8 Automatizar pruebas No es obligatorio tener todas las pruebas automatizadas y ya listas para ejecutarlas desde el servidor de integración continua. En su lugar, ve automatizando las pruebas del pipeline definido que consideres más primordiales primero y ve enlazándolas en el servidor cuando estén listas. Y no te olvides de que las pruebas que automatices son código, que deberás mantener a lo largo del tiempo.



2.9 Inspección continua Por inspección continua se entiende el ir realizando análisis de código periódicamente (por ejemplo con herramientas como SonarQube) interpretar los resultados y plantear y llevar a cabo acciones de mejora de calidad del software.

2.10 Implementar entrega continua y despliegue continuo Si tu empresa tiene superada ya la integración continua, le va bien, tiene una estrategia de pruebas y un pipeline de integración continua fiable, se puede implementar la entrega continua

(dejar el software en un estado listo para pasar a producción) y despliegue continuo (que cada cambio en el código, después de pasar por todo el pipeline de integración continua que definimos, se suba a producción).

DevOps para principiantes

Recommend Documents