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.

http://searchdatacenter.techtarget.com/es/cronica/DevOps-un-enfoque-agil-para-el-desarrollo-de-aplicaciones-moviles


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.

http://searchdatacenter.techtarget.com/es/consejo/Por-que-tomar-un-enfoque-agil-DevOps-al-modernizar-sistemas-heredados

http://searchdatacenter.techtarget.com/es/consejo/Por-que-tomar-un-enfoque-agil-DevOps-al-modernizar-sistemas-heredados


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."



Capítulo 2

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 no-

funcionales 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.



Capítulo 3

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) Sally pueda

accidentalmente sobre-escribirlos 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.



Capítulo 4

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

Documents

Transcript of DevOps para principiantes