6 /1 9 /2 0 2 0

DEVOPS ESSENTIALS
PROFESSIONAL
CERTIFICATE (DEPC®)

Objetivos

• Conocer la importancia de DevOps y aprender cómo aplicar esta metodología en

diferentes proyectos.
• Certificación profesional.

2
 6 /1 9 /2 0 2 0

¿Qué es DevOps?

¿Qué es DevOps?

La palabra es
DevOpsde
contracción
(Development) y “Desarro
una
“Operaciones” llo”
(Operations).

8
 6 /1 9 /2 0 2 0

¿Qué es DevOps?

DevOps es una nueva tendencia en la industria TI dirigida a mejorar la agilidad del

servicio de entregas en TI. El movimiento hace énfasis en la comunicación
transparente, la colaboración junto con la integración entre el software de
desarrolladores y las operaciones de TI.

¿Qué es DevOps?

DevOps reconoce que los desarrolladores y los operadores de TI son grupos con
3
relación que pueden interactuar entre sí, pero no realmente trabajar juntos.

DevOps ayuda a la organización a crear servicios TI y software de manera rápida

lo que resulta en la reducción del número de iteraciones.
 6 /1 9 /2 0 2 0

¿Qué es DevOps?
“Comunicación” y “visibilidad en
tiempo real así como automatizar el
proceso de entrega de software y los
cambios a la infraestructura

Establecer un ambiente donde realizar código,

probar y desarrollar software pueda realizarse
rápidamente, de manera frecuente y segura.

¿Qué es DevOps?

● Enfatiza en la comunicación,
colaboración entre el software de
desarrolladores y los otros
profesionales.
● Realizar códigos, probar y
desarrollar software pueda
realizarse rápidamente, de manera
frecuente y segura.
4

8
 6 /1 9 /2 0 2 0

¿Por qué DevOps?

Comunicación tradicional entre

desarrollo y operaciones.

Definiciones de DevOps

No hay un acuerdo claro y universal sobre su

definición.

Hay varias opiniones sobre qué es y qué no

es DevOps, generalmente se define como
una nueva forma de organización, una
cultura o incluso una nueva forma de
pensar.

10
 6 /1 9 /2 0 2 0

¿Qué no es DevOps?

DevOps no es automatización.

DevOps implica automatización.

DevOps es más que automatización.

11

¿Qué no es DevOps?
No es una herramienta implementada.

No debemos limitar el alcance de las

herramientas. Esto limita el amplio alcance como
si una sola herramienta de automatización se
equiparara con DevOps.

No es equipo de trabajo nuevo y separado

de las demás áreas de TI.

Tener un equipo DevOps separado, anula el

propósito de evitar las posibles fricciones y falta 6
comunicación entre los desarrolladores y
operadores de TI ya que crea un silo más.

12
 6 /1 9 /2 0 2 0

Definición de DevOps Según

sus Líderes

Nos referimos a “DevOps” como el resultado de la

aplicación de principios eficientes a la corriente de valor de
TI.

Libro de cocina de DevOps (DevOps Cookbook).

“Una mezcla de patrones destinados a mejorar la colaboración

entre desarrolladores y operadores. DevOps se dirige a
compartir metas e incentivos, así como procesos compartidos y
herramientas”.

Michael Hüttermann.

13

Definición de DevOps según

sus Líderes
“Un movimiento de personas quienes se preocupan por
desarrollar y operar sistemas fiables, seguros y de alto
rendimiento a escala”.

Jez Humble.

“DevOps es una cultura o un movimiento profesional”.

Adam Jacob, CTO at Chef.

“DevOps es como un movimiento filosófico”. 7

Gene Kim, Fundador de TripWire, CTO y Autor.

14
 6 /1 9 /2 0 2 0

Historia

Historia

2008

Durante la conferencia de Agile, 2008

celebrada en Toronto, por el desarrollador de
software Patrick Debois.

Él demostró que podía haber mejores maneras

de obtener un gran trabajo al resolver los
conflictos entre los equipos de desarrollo
y operaciones. Pronto fue reconocido como el
líder de la idea detrás del concepto de DevOps y 8
otros continuaron resolviendo estos desafíos.

16
 6 /1 9 /2 0 2 0

Historia

2009

John Allspaw y Paul Hammond, dos empleados de Flickr,

presentaron una charla, titulada “Diez despliegues en el día:
cooperación de Dev y Ops en Flickr”. Señalaron el conflicto
entre los desarrolladores y operadores al culparse entre ellos.

Inspirado por esto, Debois organizó su propia conferencia

(DevOpsDay). El nombre de este movimiento fue reducido a
DevOps después de esta convención.

17

Historia
2010

Primer DevOpsDay organizado en los Estados

Unidos tuvo a defensores de DevOps como
Andrew Clay Shafer, Damon Edwards, entre
otros.

2011

Se desarrollaron herramientas de código abierto

tales como Vagrant que funcionaba con Chef,
Puppet y herramientas de administración de
9
configuraciones similares.

18
 6 /1 9 /2 0 2 0

Historia

2012
Los DevOpsDays fueron organizados alrededor del
mundo y se convirtieron en eventos TI muy
concurridos y deliberados sobre el pensamiento
innovador en el dominio DevOps.
2013
Mike Loukides, una figura prominente en el mundo
DevOps, junto con Debois editaron algunos textos
fundamentales de DevOps.
Gran cantidad de libros sobre DevOps aparecieron.

19

Historia

2014

El mundo tecnológico en evolución presenta

nuevas oportunidades para el concepto de
DevOps en forma de explosión de nuevas
aplicaciones, dispositivos y comunicaciones en
entornos móviles y Cloud Computing.

2015+

10
DevOps es presente y futuro…

20
 6 /1 9 /2 0 2 0

Historia

21

Propósito de DevOps
11
 6 /1 9 /2 0 2 0

Propósito de DevOps

● Iterar de manera más rápida durante la fase de

desarrollo.
● Evitar la fricción entre los desarrolladores y
operadores.
● Transparencia e integración entre el equipo
de desarrollo y operaciones.
● Procesos de negocios alineados en flujo “justo a
tiempo” (JIT por sus siglas en inglés).
● Maximizar los resultados del negocio, tales
como incrementar las ventas y la rentabilidad.
● Mejorar la velocidad del negocio, o
minimizar costos operativos.

23

Propósito de DevOps

DevOps ayuda a realizar la implementación de

manera rápida y sin esfuerzo.

Por lo tanto, el propósito general de DevOps es

lograr la rapidez en el despliegue.

12

24
 6 /1 9 /2 0 2 0

Propósito de DevOps

• DevOps desea establecer la cadena de

suministros de servicios TI en el negocio, de
la misma manera que la cadena de suministro
para otros productos está incrustado.

• Desde el punto de vista arquitectónico, DevOps

necesita establecer un sistema de despliegue
automatizado rápido.

• DevOps no tiene un modelo para la

implementación, cada organización tiene que
pensar y construir su propio proceso DevOps
para mejorar su negocio.

25

Propósito de DevOps

Algunos modelos planteados.

• DevOps Implementation Framework

(DIF).
• DevOps Roadmap.
• DevOps Journey.
• DevOps Process. 13

26
 6 /1 9 /2 0 2 0

DevOps Adopción
El enfoque incremental se centra en la idea de
minimizar el riesgo y el costo de una adopción
de DevOps, construye las habilidades necesarias y
el impulso necesario para lograr una implementación
exitosa en toda la empresa.

Los "Principios de tres maneras" de Gene Kim

establecen esencialmente diferentes formas de
adopción incremental de DevOps:

1. Pensamiento de sistemas.
2. Amplificar bucles de retroalimentación.
3. La cultura de la experimentación continua y el
aprendizaje.

27

Beneficios
14
 6 /1 9 /2 0 2 0

Beneficios
● Tiempo más rápido de comercialización
de los plazos de entrega
● Mejora la rentabilidad de las inversiones
(ROI).
● Desarrollo más rápido de software y la
entrega frecuente.
● Mejorar la colaboración entre el
desarrollador y los equipos de
operación.
● Transparencia para una toma de
decisiones efectiva.
● Comunicarse y colaborar con otros
equipos de TI en el entorno dinámico actual.

29

Beneficios

● Detección temprana y la
correspondiente corrección más rápida
de los defectos.
● Lanzamiento, implementación,
supervisión y la corrección continua.
● Entrega continua con menos fallas y
mejor calidad.
● Salida al mercado y ciclos de
lanzamiento más cortos.

15

30
 6 /1 9 /2 0 2 0

Modelo CALMS

Cultura Modelo CALMS

La cultura de la empresa debe ser de colaboración,

centrada en el cliente y multifuncional.

● Las personas de diferentes equipos y con

habilidades variadas que trabajan juntas
generan mejores productos.
● Si el cliente no encuentra valor en el
producto, el producto falla.
● La tecnología pasa a segundo lugar.
16

32
 6 /1 9 /2 0 2 0

Cultura Evaluando la cultura

organizacional
Uno de los mayores retos de cualquier organización es evaluar su cultura sin sobre
estimarla. Algunas sugerencias para conocerla son las siguientes:

● Encuestar a los empleados

● Observar la comunicación interpersonal
● Echar un vistazo al estilo de liderazgo

Las empresas frecuentemente caen en una de estas

cuatro categorías:

● Clan
● Meritocracia
● Holocracia (Sin autoridad)
● Jerarquía tradicional

33

Cultura Modelando la cultura

de la empresa
La industria de manufactura requería ciertos estilos
de management. Actualmente en la economía
enfocada en los servicios, demanda otro estilo de
management y de estructuras organizaciones.

1. Evitar lo peor de la cultura tecnológica

2. Elaborar una visión inspiradora: ¿Quién eres?
¿Qué haces? ¿A dónde vas?
3. Fomentar los valores en la empresa
4. Evaluar correctamente por el impacto del
equipo y por outputs de manera individual.
17
5. Premios y reconocimientos.

34
 6 /1 9 /2 0 2 0

Cultura La cultura con DevOps

DevOps se centra en los siguientes

principios:

● Fomentar el trabajo en equipo

● Reducir silos
● Practicar el pensamiento sistémico
(Holístico)
● Aceptar el fracaso
● Comunicar, comunicar y comunicar
● Aceptar la retroalimentación
● Automatizar procesos cuando sea
apropiado

35

Automatización Modelo CALMS

Las tareas repetitivas son aburridas e ineficientes.

Lo mejor es dejarle ese trabajo a las máquinas.

Ejemplos:
● Builds
● Testing automatizado
● Deployments
● Configuración de infraestructura

18

36
 6 /1 9 /2 0 2 0

Lean Modelo CALMS

Lean no se refiere solo a la manufactura.

En DevOps se aplica a las tareas de bajo
impacto que no aportan valor al
usuario y que por lo tanto deben ser
evitadas.

Lean nos empuja a la mejora continua

en cada uno de los objetivos DevOps.

37

Lean Identificando desperdicios

Entender las diferentes categorías de desperdicios nos ayuda a identificar fácilmente

las mejoras en los procesos de nuestros sistemas.

● Procesos innecesarios: reuniones innecesaria y frecuentes, retrabajo...

● Tiempos muertos: Devs esperando infraestructura...
● Motion (Movimiento): cosas que se hacen o adquieren pero no se usan,
licencias…
● Costo de los defectos
● Sobreproducción: Desarrollo de funcionalidades que el cliente no ha pedido.
● Transporte: Movimiento de personas a otros equipos, pasar código a servidores y
repositorios.
19
● Inventario: Un producto que está a la espera de ser vendido o usado. Por
ejemplo talento sin usarse.

38
 6 /1 9 /2 0 2 0

Lean Entendiendo el desperdicio

en DevOps
Muda: desperdicio

Muri: sobrecargas

Mura: desbalanceado

Lean Erradicando el desperdicio

1. Descubrir cuellos de botella: a corto plazo y a largo

plazo.
● Capacidad limitada
● Uso ineficiente
● Personal poco capacitado.
1. Enfocarse en el impacto
● Incrementar el número de personas en el equipo
● Eliminar actividades innecesarias
● Poner un buffer (tareas pequeñas pendientes no
prioritarias)
20

40
 6 /1 9 /2 0 2 0

Métricas Modelo CALMS

Los datos son críticos en DevOps. Medir

el progreso a través de datos, nos dará
información acerca de cada aspecto en la
transformación de la organización.

Considera que el progreso nunca debe

medirse de manera individual.

Métricas Midiendo el progreso

de la organización
Personas

Asegúrate de que las personas en tu equipo son felices y están satisfechas con su
trabajo, así como también de que invierten su tiempo en cosas productivas.

También asegúrate de que la satisfacción de tu cliente es alta y asegúrate de que

permanezca así.

- Satisfacción del equipo

- El costo promedio de las reuniones
- Uso del cliente
21
- Cantidad de tickets levantados por el clientes
- Satisfacción del cliente

42
 6 /1 9 /2 0 2 0

Métricas Midiendo el progreso

de la organización
Procesos

Después de obtener métricas de las personas, medir los procesos que se llevan de
manera habitual en la organización te ayudarán a identificar las áreas de oportunidad.

- Frecuencia de los despliegues

- Tamaño de los despliegues
- Duración de los despliegues
- Tasa de defectos
- Fallas recurrentes
- Lead time
- MTTD y MTTR

43

Métricas Midiendo el progreso

de la organización
Tecnología

La tecnología y herramientas de automatización que utilicen en el sistema son

indicadores de los datos que deben monitorear:

- Cobertura en pruebas automatizadas

- Disponibilidad (SLA)
- Despliegues fallidos
- Tasas de error
- Uso y tráfico en la aplicación
22

44
 6 /1 9 /2 0 2 0

Métricas Estabilida
d

Mean Time To Recover (MTTR).

El tiempo medio de reparación (MTTR) se refiere a
la cantidad de tiempo requerida para reparar
un sistema y restaurarlo a su funcionalidad
completa.

45

Métricas Estabilidad

MTTR

23
 6 /1 9 /2 0 2 0

Sharing Modelo CALMS

Al equipo de Operaciones se le mide por

la fiabilidad y responsabilidad de una
aplicación.

A los Developers se les mide por las

funcionalidades creadas para una
aplicación.

DevOps busca crear un ambiente en

donde cada equipo enseñe al otro y así
se empoderen, creando así un solo equipo
en el que todos contribuyen.

47

Marcos relacionados a DevOps

24
 6 /1 9 /2 0 2 0

Just-in-time (JIT) o Justo

a Tiempo

También conocida como producción justo a

tiempo o el sistema de producción Toyota
(TPS), dirigida principalmente a:
● Reducir los tiempos de flujo dentro de
la producción
● Reducir tiempos de respuesta de los
proveedores y los clientes.
● Reducir costos
● Tener los insumos justo en tiempo

49

Sistema de Producción
Toyota (SPT)

El sistema se diseñó para fábricas de

automóviles, sus relaciones con
proveedores y consumidores. Este sistema
es un gran precursor para el genérico Lean
Manufacturing.

Se atribuye fundamentalmente a tres

personas: el fundador de Toyota, Sakichi
Toyoda, su hijo Kiichiro y el ingeniero
Taiichi Ohno, quienes crearon este
sistema entre 1946 y 1975. 25

50
 6 /1 9 /2 0 2 0

Kaizen

Motivación
Kaizen, término japonés para "mejora”.

Kaizen se refiere a actividades que

mejoran continuamente..

También se aplica a procesos, tales como

compras y logística que cruzan los límites
de la organización en la cadena de
suministro.

51

BIMODAL - Gartner

IT Bimodal: Dos
enfoques distintos
pero coherentes,
bastante diferentes,
ambos esenciales.

26

[Link]

52
 6 /1 9 /2 0 2 0

BIMODAL - Gartner

Bimodal está ocurriendo.

Para 2019, el 30 % de CISCOs adaptará las

prácticas de gestión de riesgos, apoyará la TI
bimodal y mejorará las tasas de éxito del modo
2, al tiempo que reducirá los costos.

[Link]

53

DevSecOps

DevOps tiene una relación nada fácil con

seguridad.

27

54
 6 /1 9 /2 0 2 0

DevSecOps

Si DevOps no presta atención a la seguridad puede facilitar la rápida introducción de

las vulnerabilidades.

Scrum Historia

• Scrum es un marco para desarrollar y mantener

productos complejos. Consiste en roles
Scrum, eventos, artefactos y las reglas que los
unen.

• Ken Schwaber y Jeff Sutherland

desarrollaron Scrum.

Fuente: [Link]/docs/scrumguide 28

49
 6 /1 9 /2 0 2 0

Scrum Proceso

49

Work in Progress, WIP

Scrum / Kanban
(Trabajo en Proceso)
Se acuerda por el equipo de desarrollo
trabajar en progresos limitados antes de
que un proyecto comience y sean
ejecutados por el facilitador del equipo.

Por ejemplo, un equipo puede dividir las

tareas que deben realizarse para una
característica en el diseño, código, prueba y
despliegue. Cuando se alcanza un límite
WIP para una determinada tarea, el
equipo se detiene y trabaja en conjunto 29
para eliminar el cuello de botella.

58
 6 /1 9 /2 0 2 0

Ciclo Plan-Hacer-Verificar-Actuar
Scrum / Kanban
(Plan-Do-Check-Act Cycle/
PDCA Cycle)
PDCA (Planear-Hacer-Verificar-Actuar o
Planear-Hacer-Verificar-Ajustar) es un
método de gestión de cuatro pasos
iterativo utilizado en los negocios para el
control y la mejora continua de procesos y
productos.

También se conoce como círculo/ciclo/rueda

de Deming, ciclo de Shewhart,
círculo/ciclo de control, o Planear-Hacer-
Estudiar-Actuar (PDSA).

59

Ciclo Plan-Hacer-Verificar-Actuar (Plan-Do-Check-Act

Cycle/PDCA Cycle)

30
 6 /1 9 /2 0 2 0

Definition of Ready

Requisitos que debe cumplir una historia

para ser considerada lista para empezar a
desarrollarse.
✓ Criterios de aceptación y escenarios
definidos
✓ La historia no cuenta con
dependencias
✓ La historia cuenta con Diseño UX o
maqueta
✓ Historia estimada y priorizada por
negocio
✓ Documentación formal en Jira
✓ Definición de servicios de backend

61

Definición de Listo
Scrum
(en Agile/Scrum)

DoD (Definition of Done):

● Requisitos que debe cumplir una
historia para ser considerada como
terminada.
✓ Se cumplieron todos los criterios
de aceptación definidos
✓ Testing funcional concluido y
con evidencias
✓ Desplegada en ambiente Pre
✓ Checklist de QAT 31
✓ Revisión visual aprobada por UX
✓ Evidencia de pruebas unitarias

62
 6 /1 9 /2 0 2 0

Kanban para Equipos DevOps

El método Kanban puede ayudar a los

equipos de DevOps a poner un poco de
orden en su trabajo diario y la teoría
Lean definitivamente puede ser
apalancada para mejorar el flujo a través
de los equipos de DevOps.

63

Kanban para Equipos DevOps

32
 6 /1 9 /2 0 2 0

DevOps y Agile

DevOps tiene varios componentes, algunos de

ellos incluyen:

• Fuerte control de la fuente.

• Automatización (automatización del software).
• Pruebas tempranas y frecuentes.
• Los pequeños incrementos en la entrega.
• Mejoras continuas.
• Equipos cohesivos: Significa trabajar en
estrecha colaboración para producir valor, para
sacar productos al mercado.

65

DevOps y Agile

XP/Agile Engineering Practices:

• Test Driven Development: Similar a las pruebas tempranas y

frecuentes.
• Pequeñas Entregas: Similar a la entrega de pequeños
incrementos.
• Integración Continua: Similar a la automatización.
• Equipo Completo: Al igual que el equipo cohesivo o el trabajo
en equipo que sucede entre los desarrolladores y los clientes. 33
• Estándares de Codificación: Similar al fuerte control de
fuentes.

66
 6 /1 9 /2 0 2 0

DevOps, Otras Prácticas Recomendadas

y Frameworks (Marcos)

Modelo en Cascada

El modelo de ciclo de vida en

cascada se comenzó a
diseñar en 1966 y se terminó
alrededor de 1970.

Se define como una

secuencia de fases donde al
final de cada una de ellas se
reúne la documentación
para garantizar que cumple
las especificaciones y los
34
requisitos antes de pasar a
la fase siguiente.
 6 /1 9 /2 0 2 0

Modelo V
Plan de pruebas de rendimiento

Plan de pruebas de integración

Plan de pruebas de diseño

Plan de pruebas

35
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos
utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la
fase de diseño.
 6 /1 9 /2 0 2 0

DevOps e ITSM (ITIL)

DevOps e ITIL se necesita

mutuamente. ¿Por qué? Porque
tienen funciones que benefician
a ambos.

DevOps puede proporcionar:

• Trabajo colaborativo.
• Tiempos de despliegue rápido y continuo.
• Entrega más rápida de funciones.
• Enfoque en el trabajo importante.
• Estabilidad en el ambiente.
71

DevOps e ITSM (ITIL)

ITIL, por otro lado, puede proporcionar:

• Estructura con su ciclo de vida.
• Relaciones de negocio.
• Mejor calidad y fiabilidad de los
servicios.
• Alcance de servicios más vigoroso
• Mejora continua.
• Mejores diseños de servicios.

Aunque DevOps, por sí solo, es un proceso

36
ya muy útil, se puede mejorar cuando une
fuerzas con ITIL.

72
 6 /1 9 /2 0 2 0

DevOps e ITSM (ITIL)

Para tener menor tiempos de entrega en los

servicios, lo cual apoya a ITIL. Muchas áreas
automatizan sus procesos, resolviendo
procesos de configuración y liberación en el
proceso de administración.

73

DevOps e
ITSM (ITIL)

DevOps
industry architecture, figure 9.
"ITIL® is a (registered)
Trade Mark of AXELOS
Limited. All rights reserved
©Copyright AXELOS.

37
 6 /1 9 /2 0 2 0

Equipo DevOps

Organización-Legado

Rendimiento, optimización de recursos, estructura y líneas de reporte, comando y

control.

38

76
 6 /1 9 /2 0 2 0

Operadores y Desarrolladores Tradicionales

Se Crean Equipos Dedicados de DevOps

39
 6 /1 9 /2 0 2 0

DevOps Total

Roles de los Equipos

• Master de Procesos.
• Master de Servicios.
• Ingeniero de DevOps.
• Coordinador de Lanzamiento.
• Ingeniero de Confiabilidad.
• Equipo de Desarrollo.
• Equipo de Operación.
40
• Etc.
(OJO el objetivo no es crear nuevas estructuras complejas)

80
 6 /1 9 /2 0 2 0

El modelo DevOps

El ciclo DevOps

41

82
 6 /1 9 /2 0 2 0

Las etapas DevOps

83

Planeación

Al igual que el modelo Agile, DevOps hace énfasis en la planeación continua de los
requerimientos y en el involucramiento del cliente para tener de manera constante
su feedback. De esa manera se pueden realizar los siguientes pasos:

1. Compartir los objetivos del negocio

2. Crear historias de usuario
3. Acotar el alcance
4. Priorizar funcionalidades
5. Diseñar personas

42

84
 6 /1 9 /2 0 2 0

Planeación

DevOps hace énfasis en involucrar al equipo

técnico en la planeación continua de los
requerimientos para tener de manera
constante su feedback. De esa manera se
compartirán puntos de vista acerca de la
complejidad de las funcionalidades.

85

Planeación

Con DevOps no solo se busca construir

software sino además diseñarlo siguiendo
algunos principios:

1. Construir software mantenible

2. Mejorar el software constantemente
3. Documentar el software
correctamente
4. Hacer sistemas escalables
5. Planear la seguridad
6. Considerar la usabilidad
43
7. Confiabilidad
8. Flexibilidad
 6 /1 9 /2 0 2 0

Desarrollo
DevOps hace énfasis el uso de buenas prácticas en el desarrollo
de software. Estas prácticas se relacionan directamente con el
marco de trabajo Extreme Programming.

● La comunicación efectiva con diferentes roles

● El manejo de errores en el código
● Escribir código mantenible
● Realizar pruebas con el código
● Depuración del código
● Logging en el código
● Usar patrones de programación (Oop, functional
programming)
● Lenguajes de programación adecuados (performance,
comodidad, comunidad, etc)
● Evitar antipatrones

87

Desarrollo

Un equipo DevOps no puede existir si el

equipo no le ve beneficio a las
automatizaciones implementadas, y los
desarrolladores son los que más se
benefician del enfoque de DevOps.

Cuando se contrate a un nuevo miembro en

el equipo, se deben considerar los valores
que muestra en el trabajo y la experiencia
técnica.
44
“¿Contratarías a un malabarista por su CV o
por una audición?”

88
 6 /1 9 /2 0 2 0

Desarrollo
La actitud de los desarrolladores es tan
importante como su expertise técnico.

● Escribir código limpio

● Entendimiento del negocio
● El arte de saber escuchar
● Enfocarse en las cosas correctas
● Abierto al cambio y a experimentar
● Buenas prácticas:
- Organizar el código fuente
- Escribir tests
- Documentación de funcionalidades
- Hacer revisión en pares

89

El síndrome del impostor

En una cultura DevOps están abiertos a

enseñar a otros y a aprender de otros, sin
miedo.

45

90
 6 /1 9 /2 0 2 0

Antipatrones de desarrollo

● Definir diseño por comité

● God objects (Objetos dios)
● Culto a patrones
● Ley del martillo
● Bleeding edge (Filo sangriento)
● Sobreingeniería
● Código espaguetti
● Copy-paste
● Optimización prematura
● Vendor lock-in (Dependencia de un proveedor)

91

Control de versiones
Sistema de control centralizado de versiones Sistema de control descentralizado de versiones

Repository Repository

Repository Repository Repository Repository

Working Copy Working Copy Working Copy Working Copy

46
Working Copy Working Copy Working Copy Working Copy
Workstation Workstation Workstation Workstation
/ PC #1 / PC #2 / PC #2 / PC #3 Workstation Workstation Workstation Workstation
/ PC #1 / PC #2 / PC #2 / PC #3
 6 /1 9 /2 0 2 0

Source Code Management

Local Remote
Working directory Staging area Local Repo Remote repo

Git add

Git commit

Git push

Git pull

Git checkout

Git merge

Testing

Si das el salto a integración continua o

entregas continuas sin establecer
pruebas automatizadas como parte
de una práctica del equipo, obtendrás
un desastre catastrófico.

47

94
 6 /1 9 /2 0 2 0

Testing

Las pruebas automatizadas tienen tres

propósitos:

● Confirmar que toda la lógica de la

funcionalidad deseada es correcta.
● Descubrir errores en el código.
● Verificar que las funcionalidades
previas no fueron afectadas con el
nuevo código.

Automatizando las pruebas

Release pipeline: Los ambientes por los

que viaja el código en su camino de
desarrollo a producción.
● local
● desarrollo
● testing
● staging
● producción
48

96
 6 /1 9 /2 0 2 0

Testing

El continuous testing toma como punta

de lanza las pruebas unitarias y crece
gradualmente en mayor o menor medida,
dependiendo de la prevención que se
busque tener con las incidencias o errores
en producción.

● Pruebas unitarias
● Pruebas de integración
● Pruebas de regresión
● Pruebas visuales
● Pruebas de performance

97

Testing

Más presión Menos pruebas

sientes escribes

El círculo
vicioso

Menos
productivo y Tu código
preciso eres es menos
estable
49

98
 6 /1 9 /2 0 2 0

Pruebas unitarias para

sistemas legado

● Mock objects
● Sprout class
● Rompiendo dependencias
● Dependencias ocultas
● Parámetros anidados
● Puntos de intercepción
● Código obsoleto
● Conservando las firmas
● Cómo saber que no estoy
descomponiendo algo más

99

Más allá de las pruebas unitarias

Los developers deben considerar tiempo

para realizar las siguientes tareas:
● Desarrollo de casos de prueba
● Escribir pruebas automatizadas
● Correr pruebas manuales(solo las
necesarias)
● Desplegar los cambios en otros
ambientes
● Hacer ajustes
50

10
0
 6 /1 9 /2 0 2 0

Integración Continua
● Cada pieza de código está integrada en el sistema
una vez que el código está listo.
● Los sistemas pueden ser integrados y construidos
múltiples veces en un día.
● Todas las pruebas se realizan y deben ser
aprobadas para que el nuevo código se incorpore
definitivamente.
● La integración continua a menudo reduce la
fragmentación de los esfuerzos de los desarrolladores.
● El equipo de desarrollo está más preparado para
modificar el código según sea necesario, porque les
confiere la identificación y corrección para los errores de
integración.

101
10
1

Integración Continua

La integración continua permite a los

desarrolladores de un equipo trabajar con el mismo
código base mientras se hacen cambios mínimos,
evitando conflictos por merge masivos.
Para implementar la integración continua se
realizan 3 pasos:

● Escribir pruebas automatizadas para cada

feature.
● Instalar un servidor CI. 51
● Desarrollar el hábito.

102
 6 /1 9 /2 0 2 0

Integración continua

Build

Compile Code Review

Integration
Unit Test
Servidor Testing
Jenkins

Package (war,
jar, etc.)
Commit a un servidor de
código compartido.

103

Integración continua

52

104
10
4
 6 /1 9 /2 0 2 0

Integración Continua

Pequeñas entregas:

La idea es producir rápidamente

versiones del sistema que estén
operativas, aunque obviamente no tienen
toda la funcionalidad prevista para el
sistema, pero son un resultado de valor
para el negocio.

105

Beneficios de la
Integración Continua

Algunos beneficios de la integración continua son:

● Testing automatizado
● Ciclos de retroalimentación acelerados
● Decremento de conflictos interpersonales
● Proceso de despliegue confiable

53

106
 6 /1 9 /2 0 2 0

Entrega continua

Build

Compile Code Review

Desplegar la aplicación
en servidor de pruebas
UAT

Integration
Unit Test
Servidor Testing
Jenkins

Package (war,
jar, etc.)

Commit a un servidor de
código compartido.

107

Entrega Continua
Los ciclos de entrega de software puede ser en
múltiples entornos o ambientes:

● QA: Ambiente de control de calidad.

● SIT: Ambiente para integración del sistema.
● UAT: Prueba de aceptación del usuario.
● Pre-prod

El despliegue automatizado es la
posibilidad de que el software se
despliegue en
54
cualquier entorno en un momento dado.

108
 6 /1 9 /2 0 2 0

Despliegue continuo

El despliegue continuo es un paso más allá

de la entrega continua. Cada cambio que
pasa el flujo de despliegue a producción es
desplegado: el código es puesto
directamente en producción.
El despliegue continuo elimina la
intervención humana del proceso de
despliegue y requiere una suite robusta de
pruebas automatizadas.

109

Despliegue continuo

Para implementar despliegue continuo se realizan 3 pasos:

● Mantener una cultura enfocada al testing.

● Documentar nuevas funcionalidades.
● Coordinación con otros departamentos: p.e. marketing

55

110
 6 /1 9 /2 0 2 0

Despliegue continuo

Build

Desplegar la aplicación
Compile Code Review en servidor de pruebas
UAT

Integration
Unit Test
Servidor Testing
Jenkins

Package (war,
jar, etc.)
Desplegar la aplicación
en servidor de
Commit a un servidor de producción
código compartido.

111
11
1

Despliegue continuo

Algunas prácticas necesarias para el despliegue continuo:

● Automatizar de la manera correcta

● Versionamientos correctos
● Mitigación de las fallas
● Rolling backs
● Fixes en producción
● Democratización de despliegues
● Elegir un estilo de despliegue
56

112
 6 /1 9 /2 0 2 0

Monitoreo continuo

Después de liberar el software es necesario monitorear la disponibilidad, la seguridad, el

rendimiento, etc.

● Entendiendo la telemetría
● Registrando comportamiento: datos y métricas
● Service Level Agreement.

El monitoreo continuo es la habilidad que tiene la organización para detectar, reportar,

contener y mitigar los ataques que puedan ocurrir en su infraestructura.

113

El ciclo DevOps

57

114
 6 /1 9 /2 0 2 0

Los 3 caminos para DevOps

The three ways

Los tres caminos de DevOps nos permite

crear una cultura de alta confianza que
apoya el enfoque dinámico, disciplinado y
científico hacia la experimentación y el
manejo de riesgos, facilitando la creación
de organizaciones que aprenden tanto del
éxito como de la falla.

Los tres caminos son un conjunto de

principios de donde se derivan
comportamientos y patrones observados en 58
DevOps.

116
 6 /1 9 /2 0 2 0

El flujo de valor

6 principios

117

El flujo de valor

1. Haz el trabajo visible.

Para que puedas ver en donde fluye

bien el trabajo y en donde se atora.
p.e. kanban o scrum board.

El trabajo no se termina cuando

Desarrollo termina la
implementación de funcionalidad,
sino cuando la aplicación se ejecuta
correctamente en producción, 59
entregando valor al cliente.

118
 6 /1 9 /2 0 2 0

El flujo de valor

2. Limita el Work In Progress.

Las interrupciones (en TI) tienen

consecuencias que son invisibles para
casi todos. Estas interrupciones son
tareas diarias como correos, llamadas,
video conferencias, reuniones, etc..
además de la asignación a múltiples
proyectos.

El tablero kanban te ayuda a limitar el

multitasking poniendo un límite a las
tareas que puede tener en cada
columna.

119

El flujo de valor

3. Reduce el tamaño de los lotes.

Entre más grande sea el cambio que despleguemos en producción, será más difícil
diagnosticarlos y arreglarlos.

60

120
 6 /1 9 /2 0 2 0

El flujo de valor

4. Reduce la cantidad de handoffs.

Cada vez que un entregable pasa de un equipo a otro se realizan diferentes actividades con él.
En cada uno de estos pasos el entregable hace fila y tiene que esperar a ser atendido. Con
demasiados handoffs es fácil que se pierda el contexto del problema que se quiere resolver. La
solución es automatizar en trabajo o reorganizar los equipos.

121

El flujo de valor

5. Identifica y eleva constantemente Mejorar métrica Creación de

del lead time ambientes de
tus restricciones. para el prueba o
despliegue producción
Paso 1. Identifica la restricción.
Paso 2. Explota a la restricción. El despliegue en
Paso 3. Subordina todo lo demás sí requiere
manuales,
relacionado a esta restricción. manejo de
Paso 4. Eleva la restricción. errores...
Paso 5. Regresa al paso 5.
Configuración y
No permitas que se generen nuevas ejecución de
Reunión con 61
restricciones por inercia. comité para
pruebas
aprobación

122
 6 /1 9 /2 0 2 0

El flujo de valor

6. Elimina las dificultades y el

desperdicio en el flujo.

● trabajo parcialmente hecho

● procesos extra sin valor
● funcionalidades no necesitadas
● switch entre tareas
● tiempos de espera
● handoffs
● defectos
● trabajo manual o sin estandarizar
● héroes

123

El feedback

5 principios

62

124
 6 /1 9 /2 0 2 0

El feedback

1. Trabajar de manera segura en sistemas

complejos: system thinking.

El pensamiento sistémico nos desafía a ver un sistema

como un todo y a entender cómo es que todas las piezas
se conectan.

Los sistemas complejos tienen un alto nivel de

interconexión de componentes altamente acoplados.

125

El feedback

2. Identificar los problemas en cuanto ocurren:

feedback y telemetría.

El objetivo es incrementar el flujo de la información en el

sistema a todas las áreas posibles de manera pronta,
rápida y barata, y además con la mayor claridad posible
entre causa y efecto.

En DevOps los datos de telemetría provienen de

registros, métricas y eventos. Las mediciones son cosas 63
como el consumo de memoria, el rendimiento de la CPU
y el tiempo de respuesta de la base de datos.

126
 6 /1 9 /2 0 2 0

El feedback

3. Practicar swarm y resolver problemas para

generar nuevo conocimiento.

En vez de darle la vuelta al problema o arreglarlo “cuando

tengamos más tiempo”, lo arreglamos inmediatamente entre
todos (swarming).

● Prevenimos que el problema pase al siguiente proceso,

donde se incrementa el costo y esfuerzo para repararlo.
● Prevenimos inyectar el error o la falla en el sistema con
el trabajo nuevo.
● Prevenimos trabajar sobre algo que tiene errores o fallas.

127

El feedback

4. Mantener el cuidado de la calidad cerca del origen: feedback entre la causa y el

efecto.

En los sistemas complejos, agregar pasos de inspección y aprobación incrementa la probabilidad

de futuras fallas.

● Requerir que otro equipo complete tareas manuales, tediosas y propensas a errores.
● Requerir la aprobación de personas ocupadas y distantes al trabajo que se desea validar.
● Crear largos volúmenes de documentación los cuales quedarán obsoletos casi tan pronto
como se terminen.
64
En vez de esto, necesitamos que cada una de las personas en el flujo de valor encuentre y corrija
errores en su propia área de control como parte de su trabajo diario.

128
 6 /1 9 /2 0 2 0

El feedback

5. Realiza optimizaciones para el proceso al que

entregas valor.

De acuerdo a Lean tenemos 2 tipos de clientes:

● cliente externo
● cliente interno

Nuestro cliente más importante es el me sigue en el flujo

de valor.

129

Experimentación y
Aprendizaje continuo

5 principios

65

130
 6 /1 9 /2 0 2 0

Experimentación y
Aprendizaje continuo
1. Habilitar el aprendizaje organizacional.
Patológica Burocrática Generadora

La información se oculta La información tal vez se Se fomenta la investigación

ignora
“Cualquier organización que diseñe un sistema
El pensamiento innovador El pensamiento innovador El pensamiento innovador
producirá un diseño que copia la estructura de es atacado es tolerado se entrena

comunicación de dicha organización.” Las responsabilidades son Las responsabilidades son Las responsabilidades son
eludidas fragmentadas compartidas

Ley de conway Se castiga el trabajo en

equipo
Se permite pero se
desmotiva el trabajo en
Se reconoce y premia el
trabajo en equipo
equipo

Se cubren las fallas Se perdona el error Se aprende del error

Las nuevas ideas se Las ideas nuevas crean Las ideas nuevas son
aplastan problemas bienvenidas

131

Experimentación y
Aprendizaje continuo

¿Forma de organización o
diagrama de arquitectura de software?

66

[Link]

132
 6 /1 9 /2 0 2 0

Experimentación y
Aprendizaje continuo

2. Institucionalizar la mejora del trabajo diario: OKR’s.

p.e. reservar tiempo para disminuir la deuda técnica,
corregir defectos, refactorizar y solucionar problemas
en el código y en los ambientes.

Cuando trabajamos diariamente en los problemas que

tratamos de eliminar, podemos erradicar del sistema
los problemas más obvios.

133

Experimentación y
Aprendizaje continuo
Administración por objetivos (APO) vs Objetivos por resultados clave (OKR)

APO OKR
¿Qué? ¿Qué y cómo?
Resultados clave
Anual Trimestral o mensual son:

Privado y fragmentado Público y transparente Específicos

Realistas
Agresivos
De arriba a abajo De abajo a arriba u horizontal Verificables
Medibles
Vinculado a bonificaciones Desvinculado de las
bonificaciones 67

Contrario al riesgo Agresivo y ambicioso

134
 6 /1 9 /2 0 2 0

Experimentación y
Aprendizaje continuo
Ejemplo: OKR de John Doerr en 1975

Objetivo: Demostrar que el rendimiento del 8080 es superior en

comparación con el de Motorola 6800. Objetivo de Intel:
Queremos dominar el
negocio de los componentes
Resultados clave: de microprocesadores de
rango medio.
1. Entregar cinco pruebas de rendimiento.
2. Desarrollar una demo. Resultados clave: Ganar
diez diseños nuevos en el
3. Desarrollar materiales para la formación del personal de ventas. 8085.

4. Llamar a tres clientes para comprobar que el material funciona.

135

Experimentación y
Aprendizaje continuo

Ejemplo: OKR de Jurgen Appelo en 2014

Objetivo: Ser un corredor más saludable. La evaluación:

1. Un incremento de 30 km a 50 km a la semana: 44%

Resultados clave: 2. Un incremento de 10 hasta 20 km al día: 100%
3. Tiempo promedio de 54 a 60 min: 100%
1. Correr 75 km a la semana (eran 30 km) 4. Con dolor en las rodillas: 75%
2. Correr al menos 10 km al día (eran 6 km) Evaluación total 80%
3. Correr un tiempo promedio < 55 min/ 10 km
4. Sin dolor en la espalda, piernas o pies
68

[Link]

136
 6 /1 9 /2 0 2 0

Experimentación y
Aprendizaje continuo
3. Líderes reforzando una cultura del aprendizaje: coaching
kata
- ¿Qué fue lo último que hiciste y que resultó?
- ¿Qué aprendiste?
- ¿Cuál es la situación actual?
- ¿Cuál es tu próximo objetivo?
- ¿Qué obstáculo estás teniendo?
- ¿Cuáles son los siguientes pasos?
- ¿Cuál es el resultado esperado?
- ¿Cuándo podemos hacer un checkpoint?

137

Experimentación y
Aprendizaje continuo

4. Transformar los hallazgos

locales en mejoras globales.
5. Inyectar patrones de
resiliencia en el trabajo diario:
Game day

69

138
 6 /1 9 /2 0 2 0

Dónde empezar con

DevOps

Dónde empezar

1. Elegir el flujo de valor para comenzar.

2. Entender bien el trabajo realizado en ese flujo de valor.
3. Diseñar nuestra organización y arquitectura considerando la
ley de Conway.
4. Dar más valor al mercado a través de la colaboración
efectiva de funciones en el flujo de valor.
5. Proteger y habilitar a nuestros equipos.

70

140
 6 /1 9 /2 0 2 0

Modelo Gartner
DevOps
Conoce el reporte DevOps

71

142
 6 /1 9 /2 0 2 0

Bibliografía recomendada

143

Contáctanos

72

144
 6 /1 9 /2 0 2 0

CertiProf ®
Professional Knowledge

[Link]
CERTIPROF® is a registered trademark of
CertiProt LLC in the United States and/or
other countries.

@Certiprof@CertiProf

73