Tema 4.

DevOps

1. Introducción
2. Integración Continua
3. Entrega Continua
4. Despliegue Continuo

Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.1 Introducción
} Desde los 70 hasta el presente:
} Jeffrey Immelt, CEO de General Electric, dijo: “Toda industria o empresa
que no incluya el software en el núcleo de su negocio terminará dañada”.

Commoditization
and Cloud

2 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.1 Introducción
} Dev & Ops:
} Los equipos de desarrollo se encargan de responder a los
cambios del mercado, desplegando las características y los
cambios tan rápido como sea posible.
} Los equipos de operaciones se encargan de proporcionar a los
clientes un servicio informático estable, fiable y seguro, que
dificulte e incluso imposibilite la introducción de cambios en
producción que puedan poner en peligro este entorno.

“El núcleo, conflicto crónico”:

• Desarrollo y Operaciones tienen
objetivos e incentivos opuestos.
• Esto conduce a la mala calidad del
software y del servicio, junto con
malos resultados para el cliente.
Además, se necesitan soluciones
diarias para encontrar alternativas,
apagar fuegos y actos heroicos.
3 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps
4.1 Introducción
} DevOps: Puppet Labs’ State Of DevOps Report recogió datos de
25000 profesionales de la tecnología:
} Despliegue del código y los cambios: 30 veces más frecuentes
} Tiempo necesario para pasar de “código en commit” a “funcionando en
producción” (lead time): 200 veces más rápido
} Despliegues a producción: tasa de éxito 60 veces mayor
} Tiempo medio para restablecer el servicio: 168 veces más rápido
} Productividad, cuota de mercado y objetivos de rentabilidad: 2 veces
más posibilidades de éxito
} Crecimiento de la capitalización de mercado: 50% superior en 3 años
} Integración de objetivos de seguridad en DevOps: 50% menos tiempo
en resolver los problemas de seguridad
} Métricas de fiabilidad
} Métricas de rendimiento
} Métricas de rendimiento organizacional
} Mayor satisfacción de los empleados, con menos tasas de agotamiento
(burnout)

4 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.1 Introducción
} DevOps: Conjunto de herramientas de desarrollo de software,
procesos y prácticas que combinan desarrollo (Dev) y operaciones
(Ops) para facilitar el ciclo de vida de desarrollo del software.
} DevOps requiere un ciclo de entrega automático que incluye:
planificación, desarrollo, pruebas, despliegue, entrega y
monitorización con cooperación activa de los distintos miembros del
equipo.
} Monitorización: El equipo de operaciones siempre debe conocer la salud y
el estado del sistema o servicio. Configurar puntos de acceso externos
para monitorizar el estado del sistema y asegurarse de que las aplicaciones
se implementan con retroalimentación hacia el sistema de métricas
operacionales.

Actividades principales:
• Integración Continua
• Despliegue Continuo

5 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.2 Integración Continua (CI)
} Proceso de integración del nuevo código implementado por los
desarrolladores, normalmente a lo largo del día, en una rama “master”
} Para asegurar que las integraciones son satisfactorias, los sistemas CI
suelen ejecutar una serie de pruebas automáticamente cuando se
añaden nuevos cambios.
} Cuando los cambios pasan al commit, todas las pruebas comienzan a
ejecutarse automáticamente para evitar que el equipo tenga que
acordarse de hacerlo.
} Ventajas:
} El software está probado y funcionando (suponiendo que se han
desarrollado suficientes pruebas) con cada nuevo cambio introducido.
Además, en cuanto se rompe se sabe, y así se puede resolver
inmediatamente.
} Los equipos que usan CI son capaces de entregar el software más rápido y
con menos defectos que los que no lo utilizan.
} Los defectos se detectan mucho antes en el proceso de entrega, cuando
son más fáciles de resolver, por lo que se reduce el coste y el tiempo
empleados.

6 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.2 Integración Continua (CI)
} Tres elementos con los que empezar a utilizar CI
} Control de Versiones. Todo lo relacionado con el proyecto debe estar
incluido en un único repositorio: código, pruebas, scripts de base de datos,
scripts para construir y desplegar, y cualquier otro elemento necesario para
crear, instalar, ejecutar y probar la aplicación.
} Build Automático. Se debe poder iniciar el proceso de construcción del
sistema automáticamente desde el entorno de integración continua para que
pueda ser auditado si algo no va bien. Los scripts se deben tratar igual que el
código de tu aplicación.
} Acuerdo con el Equipo. Todos deben confirmar (check in) sus cambios en
forma de pequeños incrementos frecuentemente y acordar que la tarea con
mayor prioridad es resolver cualquier problema que rompa el código.

Commit Stage
Push 1.Compile
2.Build
3.Test

Tú Servidor
7 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps
4.2 Integración Continua (CI)
} Prácticas a aplicar
} Confirma tus cambios regularmente. Al menos dos veces al día.
} Crea una Suite de Pruebas Automatizadas Completa. Es esencial tener un
nivel de pruebas automatizadas para ofrecer la seguridad de que la aplicación
realmente funciona. Habitualmente: pruebas unitarias, de integración y de
aceptación.
} Mantén el Proceso de Construcción y Pruebas Rápido y Efectivo. Si no,
corres el riesgo de que el equipo abandone su uso.
} Gestiona el Entorno de Desarrollo: Utiliza la Gestión de la Configuración, no
sólo para el código, sino también para datos de pruebas, scripts de base de
datos, scripts de construcción y despliegue… En general, todo el equipo debe
usar el mismo entorno de desarrollo.

Commit Stage
Push 1.Compile
2.Build
3.Test

Tú Servidor
8 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps
4.2 Integración Continua (CI)
} Arquitectura de Integración Continua:

9 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.3 Entrega Continua
} Los Candidatos a ser Entregados (Release Candidate):
} Un cambio en el código puede o no ser entregable.
} Si te fijaras en un cambio –sea una nueva característica, una solución
a un defecto, o un cambio en el rendimiento- y te preguntaras,
¿Deberíamos liberar este cambio? La respuesta es que el proceso
de construcción (build), despliegue y pruebas que se le aplica valida
si el cambio puede ser liberado o no.
} Cada cambio es, en efecto, un release candidate. Cada vez que un
cambio se añade (commit) al control de versiones, la expectativa es
que pasará todas las pruebas, resultará en código funcional y se
podrá desplegar en producción.
} La Entrega Continua se encargará de desplegar cada release
candidate en producción (o un entorno similar): Se presupone
que los cambios añadidos al control de versiones mejoran el sistema
en que se incluyen. ¿Cómo sabemos si es cierto? La única forma de
saberlo es a través de probar el software para comprobar si alcanza el
valor que se esperaba.
10 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps
4.3 Entrega Continua
} El proceso de despliegue de cambios a producción (o entornos
similares) mediante la definición de pruebas y validaciones para
reducir el riesgo al mínimo.
} Entrega continua significa que los cambios se despliegan en
producción bajo petición.
} Cuanto más rápido se incluyan los cambios en producción, antes se
verá el trabajo funcionando.
} La entrega continua también ofrece el producto al cliente antes, lo
que puede significar un aumento de la satisfacción del cliente.
} Un pipeline de despliegue es, en esencia, una implementación
automatizada del proceso de construcción (build), despliegue,
prueba y entrega de la aplicación.

11 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.3 Entrega Continua
} Pipeline de Despliegue

12 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.3 Entrega Continua
} Un pipeline de despliegue es, en esencia, una
implementación automatizada del proceso de construcción
(build), despliegue, prueba y entrega de la aplicación.

} El objetivo del pipeline de despliegue es triple:

1. Primero, hace que todas las partes del proceso de construcción,
despliegue, prueba y entrega del software sean visibles para
cualquier persona involucrada en el proyecto.
2. Segundo, mejora la retroalimentación para que los problemas se
identifiquen y resuelvan tan pronto como sea posible.
3. Finalmente, permite que los equipos desplieguen y entreguen
cualquier versión de su código a cualquier entorno cuando lo
deseen a través del proceso automatizado.

13 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.3 Entrega Continua
} Principios:
1. Crear un proceso repetible y fiable para entregar software

2. Automatizar todo lo que sea posible

3. Almacenar todo en el Control de Versiones

4. Si duele, hazlo más frecuentemente y hazlo prioridad

5. Construye calidad

6. Hecho significa entregado

7. Todo el mundo es responsable del proceso de entrega

8. Mejora Continua

14 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.4 Despliegue Continuo (CD)
} El despliegue continuo va un paso más allá de la
entrega continua. Ahora todos los cambios pasan a
través de todas las etapas del pipeline hasta que es
entregado a los clientes. No existe intervención
humana y cualquier fallo en las pruebas evita que el
cambio sea desplegado.
} El despliegue continuo es una forma excelente de
aumentar el bucle de retroalimentación con los
clientes y reducir la presión del equipo, ya que no
existe el día del despliegue. Los desarrolladores
pueden centrarse en construir software, porque su
trabajo se hace visible pocos minutos después de
implementarlo.
15 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps
4.4 Despliegue Continuo (CD)
} Integración Continua vs
Entrega Continua vs
Despliegue Continuo
Automático
Integración Manual
Continua
Pruebas de Despliegue Despliegue a
Build Pruebas Producción Smoke Test
aceptación a Staging

Entrega Continua

Pruebas de Despligue Despliegue a

Build Pruebas Producción Smoke Test
aceptación a Staging

Despliegue Continuo

16 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

4.4 Despliegue Continuo (CD)
} CI/CD Para Azure Web Apps (AppForMovies)
5. Despliegue a Web Apps.

3. Disparador para ejecutar las

pruebas de la aplicación con 4. Disparador para orquestar el
Integración Continua Despliegue Continuo de los artefactos
de la aplicación con los parámetros
2. Commit del código de propios del entorno.
la aplicación y del fichero
web.config 6. Azure Application Insights
recoge y analiza datos de salud,
rendimiento y uso.

1. Cambio del código fuente. 7. Revisar la salud, el rendimiento

y el uso de la aplicación

8. Actualizar el ítem del backlog (work item)

17 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps

Referencias
} [IEEE24765] ISO/IEC/IEEE 24765-2010 Systems and software
engineering — Vocabulary
} JEZ HUMBLE AND DAVID FARLEY, Continuous Delivery: Reliable
Software Releases through Build, Test, and Deployment Automation,
Wiley, 2012

18 Escuela Superior Ingeniería Informática - Ingeniería del Software II - Tema 4. DevOps