Certificacion DevOps Master PDF

Certificación DevOps Master
Bienvenida e Introducción
Temas Básicos
 Registro, Asistencia y Evaluación

 Horario de clases
 Teléfonos, Tablets y Celulares
 Principios Básicos
 Kit del Participante
 Presentación de los Participantes
 Antes de Comenzar
Bienvenida e Introducción 3
Registro, Asistencia y Evaluación
 Asistencia Controlada
 Curso Evaluado en la Ultima Sesión
 Alumno Evaluado en la Ultima Sesión con un Examen
 Para aprobar el curso se debe aprobar este examen
 Diploma por Asistencia/Aprobación
 Independiente de la evaluación se puede optar a la
Certificación
 La Certificación puede ser realizada en cualquier
institución acreditada
Horario de Clases en Modalidad 6 Sesiones
 Cinco Sesiones
 Inicio: 18:00 hrs.
 Término: 22:00 hrs.
 Un break de 0:15 hrs. por sesión
Celulares, Tablets y Notebooks
 Dedicados al curso
 Si van a estar en el trabajo en otro lado … mejor no estén el curso
Principios Básicos
 Intentar al máximo sentirse libres

 Estamos acá para aprender … aprovechemos la instancia
 El que quiere aprender eres tú … nadie mas puede hacerlo por ti
Kit del Participante
Documentos electrónicos conteniendo:

 Diapositivas del Curso
 Guía de Preparación
 Actividades
 Examen de Ejemplo
 Formulario de Evaluación del Curso
 Material de Referencia Adicional
Algunos documentos se entregan clase a clase
La correcta preparación para aprobar el examen comienza con una revisión cuidadosa de la Guía
de Preparación del Curso
Antes de Comenzar …
Principios Básicos
 Intentar pasarlo bien aprendiendo
 Buenas vibras
 Cubrir lo básico
 Afianzar lo aprendido
 Pensar y actuar
¿Preguntas?
Agenda del Curso en Modalidad de 5 Días
DIA 1
Bienvenida
Módulo 1: Adopción de DevOps
DIA 2
Módulo 2: Planificación, Requerimientos y Diseño
DIA 3
Módulo 3: Desarrollo y Despliegue
DIA 4
Módulo 4: Operación y Escalado
Módulo 5: Fin de la Vida Útil
DIA 5
Módulo 6: Actividades Prácticas
Módulo 7: Preparación de Examen
Cierre
Objetivos y Agenda del Curso
Basado en la Guía de Preparación EXIN DevOps Master Edición 201703

Visión General de DevOps
El término DevOps es una contracción de las palabras inglesas "Development" (Desarrollo) y

"Operations" (Operaciones). DevOps es un conjunto de prácticas recomendadas que enfatizan la
colaboración y la comunicación entre los profesionales de TI (desarrolladores, administradores,
operadores, personal de asistencia técnica) en el ciclo de vida de las aplicaciones y los servicios, lo
que conduce a:
 Integración Continua: transferencia sencilla desde Desarrollo hasta Operaciones y Soporte
 Despliegue Continuo: publicación de versiones de forma continua o con la máxima frecuencia
posible
 Retroalimentación Continua: búsqueda de retroalimentación de las partes interesadas durante
todas las etapas del ciclo de vida
DevOps cambia la forma en la que las personas piensan sobre su trabajo; DevOps valora la diversidad
del trabajo realizado, respalda los procesos intencionados que aumentan la velocidad a la que las
empresas crean valor y mide el efecto del cambio técnico y social. DevOps es una manera de pensar y
una manera de trabajar que permite a las personas y a las empresas desarrollar y mantener
procedimientos de trabajo sostenibles.
Objetivos y Agenda del Curso 12

Un DevOps satisfactorio consiste en:

 Promover una cultura libre de culpa en la que se compartan historias y se desarrolle la empatía
para conseguir que las personas y los equipos desempeñen sus funciones de forma eficaz y
duradera.
 Proporcionar aplicaciones y servicios al Negocio según el modelo Just-in-Time (JiT).
 Garantizar la continuidad de los servicios de TI mediante una aproximación a las necesidades de
negocio basada en el riesgo.
 Gestionar el ciclo de vida completo de las aplicaciones y los servicios, incluidas las condiciones de
fin de la vida útil.

Esta Certificación
Esta certificación pretende aportar competencias prácticas al conocimiento con el fin de que una
persona con la certificación DevOps Master pueda implementar el modelo DevOps de forma
satisfactoria en un equipo y promover sus principios en la empresa.
Esta certificación ha sido desarrollada en colaboración con expertos en el sector DevOps

Contexto de DevOps

Agenda del Curso DevOps Master

Módulo 2 Planificación, Requerimientos y Diseño
Módulo 7: Preparación del Examen

Contenido cubierto en el curso
 El curso cubre el contenido detallado por la guía oficial vigente

 El curso cubre competencias sobre:
Adopción de DevOps
Planificación, Requerimientos y Diseño
Desarrollo y Despliegue
Operación y Escalado
Fin de la Vida Útil
 El curso además contempla el desarrollo de actividades prácticas en las que se deben aplicar los
conocimientos adquiridos

Bibliografía recomendada
A Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

 Jennifer Davis, Katherine Daniels
 ISBN-13: 978-1491926307 or ISBN-10: 1491926309
 O'Reilly Media; 1 edition (June 25, 2016)
B Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
Automation
 Jez Humble, David Farley
 ISBN-13: 978-0321601919 or ISBN-10: 0321601912
 Addison-Wesley Professional; 1 edition (August 6, 2010)
C Success to Enterprise DevOps

 Koichiro (Luke) Toda, President Strategic Staff Services Corporation and Director of TPS Certificate
Institution
 Nobuyuki Mitsui, CTO of Strategic Staff Services Corporation
 White Paper; June 2016 (download from EXIN website DevOps certification page)

Bibliografía Adicional recomendada
D The Phoenix Project

 Gene Kim, Kevin Behr, George Spafford
 ISBN-10: 0988262576
 ISBN-13: 978-0988262577
 IT Revolution Press (January 10, 2013)
E Other sources:
 http://newrelic.com/devops
 http://devops.com/

ACTIVIDAD [PAGINA 1]
1 CONOCIMIENTOS PREVIOS NECESARIOS

Módulo 1
Adopción de DevOps
Agenda del Curso


Objetivos del Módulo
En este módulo el alumno reconocerá los elementos centrales de:

 Mentalidad DevOps y sus Beneficios
 Cultura Organizativa
 Principios y Conceptos
Módulo 1 Adopción de DevOps 23

Módulo 1
Adopción de DevOps
La Mentalidad y Beneficios de DevOps
Objetivos de la Sección
En la sección de Mentalidad y Beneficios de DevOps el alumno será capaz de:

 analizar anti patrones DevOps en un escenario dado
 explicar los beneficios de DevOps
 explicar por qué DevOps encaja tan bien en los procesos de desarrollo de software actuales
 explicar por qué DevOps requiere de una forma especial de pensamiento para funcionar
 explicar cómo encaja DevOps con las prácticas Lean y Agile Scrum

DevOps
 DevOps tiene como objetivo establecer una cultura y un entorno donde construir, probar y liberar
software y servicios puede ocurrir rápidamente, con frecuencia y con un mínimo de apoyo, con el
fin de aumentar continuamente la ventaja del negocio y la satisfacción del cliente.
Los principales elementos de DevOps son:

 Implementación de una cultura libre de culpa, diversa, en la que se vuelve fácil el fallar rápido y a
menudo
 Proporcionar aplicaciones y servicios para el negocio Just-in-Time (JiT), optimizando la entrega
continua (Agile) y asegurando frecuentes bucles de retroalimentación
 Asegurar la continuidad de los servicios de TI mediante un enfoque basado en el riesgo de las
necesidades del negocio
 Gestión del ciclo de vida de aplicaciones y servicios, incluidas las condiciones de fin de vida

1 MENTALIDAD DEVOPS

DevOps
 La palabra DevOps es una contracción de 'Desarrollo' y 'Operaciones'

 DevOps es un conjunto de mejores prácticas que enfatizan la colaboración y comunicación
de los profesionales de TI (desarrolladores, operadores, otras partes interesadas) en el ciclo de
vida de las aplicaciones y servicios
 Hace hincapié en la cooperación en toda la organización y la automatización de la entrega
y los cambios de infraestructura, lo que lleva a integración continua, despliegue continuo
y entrega continua

Patrones y anti patrones en DevOps
Hay varios anti patrones comunes que impiden un proceso de versión fiable, sin embargo son tan
comunes como para ser norma en nuestra industria.
Ejemplo de anti patrón: Implementación manual de software
Otros anti-patrones:
 Cultura de la culpa
 Silos
 Análisis de causa raíz - se centran en una causa raíz en lugar de muchos factores contribuyentes
 Error humano - el error humano siempre está dentro del contexto, no culpar a un individuo

Patrones y anti patrones en DevOps
Diseño
Diseño,
Construcción,
Constru Setup del Prueba, Setup del
cción Deploy
Release Release, Deploy,
Feedback
Prueba
Pre-Devops Development Pre-Devops Operations

Devops Team
Team Team
Lento, manual, multi-equipos no trabajando juntos, Rápido, automatizado, equipo

propenso a error único, mayor tasa de éxito

2 ANTI PATRONES

Beneficios de DevOps
 Un negocio sostenible y exitoso es más que los equipos de desarrollo y operaciones. Limitar
nuestro pensamiento sólo a aquellos equipos que escriben software o lo implementan en
producción puede arriesgar a todo el negocio.
 El Informe 2015 State of Devops, publicado por Puppet, encontró que las empresas que están
haciendo DevOps superan a los que no lo hacen. Que el énfasis en tener equipos e individuos
trabajando juntos es mejor para los negocios que los silos llenos de ingenieros que no juegan bien
con otros. Las organizaciones de alto desempeño desarrollan el código con más frecuencia, tienen
menos fallos, se recuperan de esos fallos más rápido y tienen empleados más felices. Tendencia de
centrarse en los resultados más que en las personas y los procesos.

 Centrarnos en la cultura y los procesos estimula la iteración y la mejora de cómo y por qué
hacemos las cosas. Cuando cambiamos nuestro enfoque de qué a por qué, se nos da la libertad y
la confianza para establecer la significación y el propósito de nuestro trabajo, que es un elemento
clave de la satisfacción en el trabajo.
 La introducción de DevOps ha cambiado nuestra industria centrándose en las personas y los
procesos a través de los papeles para alentar la colaboración y la cooperación, en lugar de competir
con la especialización.
 Como dijimos, nuestro objetivo como profesionales de software es entregar software útil y de
trabajo a los usuarios lo más rápido posible. La velocidad es esencial porque hay un costo de
oportunidad asociado con la no entrega de software. Sólo puede empezar a obtener un retorno de
su inversión una vez que su software se libera.
 DevOps no es sólo soporte IT. La exploración de DevOp también se utiliza para apoyar la
estrategia del negocio y para mejorar procesos del negocio.

 Las empresas que utilizan DevOps están superando a los que no lo usan
 Cambiar el enfoque de qué a por qué - cuestionar, innovar, colaborar
 Repetible, confiable y predecible
 Respuesta más rápida a las necesidades empresariales
 Mayor rentabilidad de la inversión en software
 Los principios de DevOps también pueden aplicarse al negocio

Integración suave de DevOps dentro del proceso de desarrollo actual
 El software que creamos no existe por separado de las personas que lo utilizan y de las personas
que lo crean. Devops trata de encontrar maneras de adaptarse e innovar la estructura social, la
cultura y la tecnología para trabajar más eficazmente.
 Existen muchas metodologías de desarrollo de software, pero se centran principalmente en la
gestión de necesidades y su impacto en el esfuerzo de desarrollo. Hay muchos libros excelentes
que cubren en detalle diferentes enfoques para el diseño, desarrollo y pruebas de software; pero
cubren sólo un fragmento de la cadena de valor que entrega valor a las personas y organizaciones
que patrocinan nuestros esfuerzos.

 ¿Qué sucede una vez que se identifican los requisitos, las soluciones diseñadas, desarrolladas y
probadas?
 ¿Cómo se unen y coordinan estas actividades para hacer que el proceso sea tan eficiente y
confiable como podamos hacerlo?
 ¿Cómo podemos permitir que los desarrolladores, probadores, personal de construcción y
operaciones trabajen juntos de manera efectiva?
 DevOps describe un patrón eficaz para obtener el software desde el desarrollo hasta la liberación.
Describimos técnicas y prácticas recomendadas que ayudan a implementar este patrón y muestran
cómo este enfoque se relaciona con otros aspectos de la entrega de software.
 El patrón central es la canalización (pipeline) de despliegue. Una canalización de despliegue
es, en esencia, una implementación automatizada del proceso de creación, implementación, prueba
y liberación de la aplicación. Cada organización tendrá diferencias en la implementación de sus
pipeline de despliegue, dependiendo de su valor

 El software no existe por separado de los usuarios y desarrolladores

 Métodos de desarrollo de software se centran principalmente en el desarrollo con poco vínculo con
el despliegue y las operaciones
 DevOps trata de adaptar e innovar la estructura social, la cultura y la tecnología para trabajar más
eficazmente

DevOps establece una nueva forma de ver el trabajo
 DevOps es un movimiento cultural que cambia la forma en que los individuos piensan acerca de su
trabajo, valora la diversidad del trabajo realizado, apoya procesos que aceleran la valorización de
las empresas y mide el efecto del cambio social y técnico. Es una forma de pensar y una forma de
trabajar que permite a individuos y organizaciones desarrollar y mantener prácticas de trabajo
sostenibles.
 Es un marco cultural para compartir historias y desarrollar empatía, permitiendo a personas y
equipos practicar sus actividades de manera efectiva y duradera.
 Uno de los fundamentos del es la necesidad de retroalimentación rápida.
 DevOps no es una sola herramienta, metodología, conjunto de habilidades u organización. DevOps
es un marco que combina todas estas para que las organizaciones establezcan procesos de flujo
continuo que permitan al negocio operar más rápido y reaccionar a los cambios más rápidamente.
DevOps también puede permitir la madurez utilizando el Ciclo Plan-Do-Check-Act de Deming.

 El entorno tradicional ve "el error humano como la causa de los problemas".

 Esta "vieja visión" se describe como una mentalidad en la que el foco está en la eliminación del
error humano. Los errores se producen por "manzanas malas" que necesitan ser expulsados.
 Esta visión se encuentra en culturas de culpa, ya que asume que los errores son a menudo
causados por malicia o incompetencia.
 Los individuos responsables del fracaso deben ser culpados y avergonzados (o simplemente
despedidos).
 El enfoque DevOps ve "el error humano como un síntoma de problemas más profundos en
el sistema".
 Esta "nueva visión" es una mentalidad que ve los errores humanos como estructurales más que
personales.
 La gente toma decisiones y toma las acciones basadas en su contexto y lo que tiene más sentido
para ellos, no la malicia intencional o la incompetencia. Las organizaciones deben considerar los
sistemas holísticamente cuando buscan minimizar o responder a los problemas. Comprender y
abrazar la "nueva visión" es la clave para entender el movimiento DevOps. Esta visión nos anima a
compartir historias, ya que todo es una oportunidad de aprendizaje.

Visión Antigua Visión Nueva(Devops)

• Eliminar el error humano • Sistemas / métodos holísticos
• Silos • Compartir historias,
• Cultura de la culpa comentarios
• Valorar a los individuos

DevOps se alinea con Lean y con las Prácticas Agiles
 DevOps no sólo es una mejora del desarrollo ágil y entrega continua, sino también la gestión de
servicios de TI y gestión de aplicaciones para permitir el crecimiento del negocio y mantener la
continuidad del negocio.
 Frecuente entrega de código utilizable, moviéndose hacia implementaciones más pequeñas, más
frecuentes en lugar de grandes, infrecuentes;
 Mejora reflexiva, o utilizando reflexiones sobre lo que funcionó bien y lo que funcionó mal en
trabajos anteriores para ayudar a guiar el trabajo futuro; y comunicación osmótica entre los
desarrolladores -la idea de que si los desarrolladores están en la misma sala, la información fluirá a
través del fondo para ser recogida informalmente, como por ósmosis.
 XP es el desarrollo ágil que fue diseñado para ser más sensible a los requisitos cambiantes que las
metodologías de software de desarrollo anteriores, y es reconocido por sus ciclos de lanzamiento
cortos, pruebas extensas y programación de pares.
 Los practicantes de DevOps han descubierto que para alcanzar estos objetivos -bajo tiempo de
ciclo y alta calidad- se necesita hacer liberaciones frecuentes y automatizadas del software.

DevOps se alinea con Lean y con las Prácticas Agiles
• Mejora continua
• Eliminación de
Lean actividades
innecesarias
Agile
• Respuesta a las necesidades
cambiantes
Devops
• Ciclos de liberación más
cortos
• Colaboración
3 CASO DE NEGOCIO

Módulo 1
Adopción de DevOps
La Cultura Organizativa
En la sección de Cultura Organizativa el alumno será capaz de:

 explicar la importancia de los cuatro pilares para un DevOps efectivo (Colaboración, Afinidad,
Herramientas y Escalado)
 analizar un escenario en busca de carencias en alguno de los elementos que componen la
mentalidad DevOps
 explicar cómo crear un equipo a partir de un grupo de personas fomentando la colaboración, la
mentalidad DevOps, la empatía y la confianza
 analizar una situación en la que haya ideas erróneas sobre la colaboración y sugerir métodos que
resuelvan el problema
 analizar una situación en la que exista la necesidad de gestión de conflictos y plantear la mejor
solución
 explicar cómo la gestión de recursos humanos puede fomentar la diversidad y el impacto
beneficioso de ésta sobre la organización

Los 4 Pilares de un DevOps efectivo
Colaboración Afinidad Herramienta Escalado

• Dirigido a un • Objetivos • Un acelerador y • DevOps puede
resultado organizacionales un ahorro de ser aplicado en
específico a compartidos, costos, pero que diferentes
través del apoyo empatía y debe ajustarse a organizaciones a
a las aprendizaje entre los métodos de medida que
interacciones y el diferentes grupos trabajo crecen, maduran
aporte de de personas e incluso se
múltiples reducen
personas

4 LOS 4 PILARES

Los 4 Pilares de un DevOps efectivo
 La combinación de loa cuatro pilares permitirá abordar los aspectos culturales y técnicos de la
organización. Tiene sentido que la organización se centre en uno o dos pilares a la vez mientras
intenta hacer cambios, pero en última instancia, es la combinación de los cuatro trabajando juntos
lo que permitirá un cambio duradero y efectivo.
 Es importante no pasar por alto los dos primeros pilares, que cubren las normas y valores de
culturales y las interacciones interpersonales, en vez de saltarse directamente a las herramientas o
al escalado.
 El uso efectivo de herramientas es necesario para una transformación de DevOps exitosa, pero no
suficiente, si fuera el caso, podríamos simplemente usar una lista de las mejores prácticas para
Chef o Docker. Sin embargo, para la resolución de los conflictos interpersonales e inter temas que
surgen dentro de las organizaciones es fundamental fomentar las relaciones duraderas que en
última instancia, se logran en un ambiente de DevOps.

La mentalidad que requiere DevOps
 Pensamientos fijos: talentos y habilidades son innatos

 Pensamiento en crecimiento: talentos y habilidades son aprendidas y mejoradas con la práctica
Se debe buscar:
 Aprender de los errores, no culpar
 Retroalimentación positiva, frecuente y constructiva
 Comunicación, escucha activa

La mentalidad que requiere DevOps
 Las mentalidades son nuestras creencias personales sobre nosotros mismos, y cómo nos
acercamos a nuestras posibilidades.
 Con una mentalidad fija, las personas creen que los talentos y habilidades son rasgos innatos y
fijos, o bien son naturalmente buenos en algo o no lo son, y ese estado es inmutable.
 En una mentalidad de crecimiento, los talentos y habilidades se aprenden y mejoran con
esfuerzo y práctica.
 Las mentalidades pueden tener un gran impacto en la forma en que la gente trabaja, aborda
desafíos y lidia con el fracaso.

5 MENTALIDAD

Colaboración
Alcanzar
Devops
Confianza los Mindset
objetivos
Empatía

6 SUPERHEROES

 El capital social, o el valor de las redes sociales de las personas y las interacciones, funcionan a
través de un mayor flujo de información, reciprocidad y utilidad, e interdependencia y confianza.
 Un equipo que se centra en torno a un empleado de superestrella, donde la ayuda y la información
es probable que fluyan sólo en una dirección, no presenta interdependencia, y es probable que
haya muy poca confianza.
 El capital social toma tiempo para desarrollarse, y sus beneficios se hacen cada vez más evidentes
a medida que avanza el tiempo.
 Para conseguir equipos productivos y las organizaciones que queremos, debemos dejar de
centrarnos en los empleados de la "superestrella" que erosionan la confianza y el capital social, y
en cambio nos centramos en la empatía creciente entre nuestros equipos existentes y trabajando
hacia la cooperación en lugar de la competencia.

 Para que un equipo trabaje mejor hacia sus metas, sus miembros deben ser capaces de trabajar
juntos.
 Los equipos con más colaboración son más productivos en su conjunto, así como vistos más
favorablemente por sus miembros
 Debido a que una menor rotación suele ser mejor para la moral y la productividad del equipo, se
trata de un ciclo de refuerzo positivo.
Colaboración 1
 Responsable individual
 Coordinación de otros
Colaboración 2
 Dos o más trabajando juntos
 Trabajando continuamente hacia el objetivo
 Ambos son métodos válidos apropiados para diferentes escenarios.

Problemas y métodos a tener presentes al colaborar
Problema: Algunas personas en el equipo no están cargando su propio peso

 Aclarar las funciones y responsabilidades
 Medir las competencias y permita el aprendizaje
 Buscar las razones - agotamiento, problemas personales, etc.
Problema: Algunas personas no están comunicando lo suficiente

 Tratar de evaluar los factores subyacentes
 Asegurar la confianza, guiar con el ejemplo

 Es importante reconocer el valor y el propósito de las diferentes formas de colaboración. Algunos

trabajos colaborativos se realizan en coordinación con otros, con un solo individuo responsable de
algún trabajo colectivo y enfocado en lograr su parte hacia el objetivo mutuo.
 Otro trabajo colaborativo se realiza continuamente, con dos o más personas trabajando juntos para
lograr un objetivo. Estos enfoques colaborativos son la elección correcta dependiendo del trabajo y
el contexto circundante.
 Los problemas surgen al colaborar eficazmente cuando las personas tienen diferencias en los
antecedentes profesionales e individuales que crean fricción si no se manejan. Ser capaz de ayudar
a las personas a identificar, moldear y trabajar activamente hacia sus diferentes motivaciones y
metas es una gran parte de ser capaz de dirigir a la gente, ya sea en una capacidad oficial como
gerente o en cualquier posición de liderazgo individual de nivel de contribuyente.

 Muchos conceptos erróneos acerca de la colaboración en última instancia tienen que ver con las
preocupaciones acerca de cuánta gente está dispuesta o es capaz de aprender y crecer dentro de
sus roles o en la organización en general.
 Las nuevas habilidades requieren tiempo y práctica para todos. No asuma que cualquier persona
mayor que usted, diferente de usted, o con un fondo diferente del suyo es incapaz de aprender.

Situaciones que pueden requerir gestión de conflictos y la mejore solución
 Pensar en los valores por sobre la cultura

 Compartir historias y experiencias
 ¿Qué tipos de problemas estamos tratando de resolver?
 ¿Estamos resolviendo los problemas correctos?
 ¿Tiene nuestro equipo el conocimiento y la experiencia necesarios para reconocer el problema y
comprender las repercusiones que sus posibles soluciones podrían tener?

7 PROBLEMAS

Situaciones que pueden requerir gestión de conflictos y la mejore solución
 Cada uno de nosotros tiene un fondo cultural diferente con experiencias únicas que informan
nuestras opciones de cómo y por qué trabajamos.
 Respetar nuestras diferencias individuales puede ayudar a construir la comprensión mutua y
resolver conflictos de una manera que es crucial para el compacto de DevOps.
 Hay grandes beneficios que pueden obtenerse de diversos equipos en términos de creatividad,
resolución de problemas y productividad, pero esta diferenciación puede conducir a conflictos
interpersonales a corto plazo, ya sea personal o profesionalmente.

La gestión de RRHH
 Reclutar una mezcla de individuos

Género, sexo, religión, raza, color, edad, habilidad, nivel educativo, experiencia
 Asegurar que las condiciones y métodos de trabajo se adapten a la diversidad
 Considerar puntos de vista diferentes y capacidad de desafiar, cuestionar, innovar, retroalimentación

La gestión de RRHH
 Aumentar la diversidad de un equipo significa asegurar una gama más amplia de antecedentes
personales.
 Incluyendo aspectos como el género, la sexualidad, la raza, la clase, el idioma primario, la habilidad
y el nivel educativo, diversos antecedentes personales pueden aumentar la fuerza de una
organización basada en la ingeniería, centrada en el producto o en el apoyo al cliente al aportar un
mayor número de experiencias y puntos de vista a la mesa.
 Una fuerza laboral diversa beneficia a los equipos, las organizaciones y la industria en su conjunto.

La gestión de RRHH
 Un departamento de recursos humanos que entiende las preocupaciones relacionadas con la

diversidad es una parte crítica de la organización para ayudar a prevenir la fricción entre las
personas debido a este tipo de diferencias personales. Los contribuyentes y gerentes individuales
deben ser capaces y alentados a tomar un sesgo de sesgo inconsciente para ayudar a explorar las
suposiciones que están impactando e influyendo en sus interacciones de trabajo.
 Los estudios han demostrado que los equipos más diversos a menudo verán más conflictos en el
corto plazo, estos efectos se equilibran no sólo por el hecho de que la creatividad y la solución de
problemas beneficios a largo plazo superan estos costos, sino también por el hecho de que el
equipo Los miembros aprenderán a colaborar y trabajar bien con una variedad más amplia de
personas.

Módulo 1
Adopción de DevOps
Principios y Conceptos
En la sección de Principios y Conceptos el alumno será capaz de:

 explicar el uso y la utilidad de las diferentes metodologías de desarrollo de software (Waterfall,
Agile, Scrum) y sus principios básicos
 explicar el uso y la utilidad de las diferentes metodologías utilizadas en operaciones (IT Service
Management (Gestión de Servicios TI))
 explicar el uso y la utilidad de los métodos Lean

Metodologías de Desarrollo de Software y sus Principios
Scrum (un método

Cascada Ágile
Agile)
• Proceso de gestión de • Más ligero y flexible • Se centra en
proyectos que los métodos maximizar la
• Progresión secuencial anteriores como la capacidad de un
de una etapa a la cascada equipo de desarrollo
siguiente • Se centra en las para responder
• Tiempo gastado al personas, las rápidamente a los
inicio del ciclo de vida interacciones y la cambios en los
se reduce para colaboración requisitos
errores posteriores • Se obtiene software • Historias, Sprints,
que funciona reuniones Scrum
rápidamente en diarias, Scrum
breves iteraciones Master, definición de
hecho

 Devops no está tan rígidamente definido como para prohibir cualquier metodología en particular.
 Si bien DevOps nace de la administración del sistema Ágil y la cooperación entre los equipos de
desarrollo y operaciones, los detalles de su práctica son únicos por medio ambiente. Una parte
clave de DevOps es poder evaluar y evaluar diferentes herramientas y procesos para encontrar los
más eficaces para su entorno.
 Cascada - Las etapas originales fueron la especificación de requisitos, diseño, implementación,
integración, pruebas, instalación y mantenimiento, y el progreso fue visualizado como fluyendo de
una etapa a otra (de ahí el nombre).

Valores ágiles:
 Individuos e interacciones por sobre procesos y herramientas
 Software que funciona por sobre documentación
 Colaboración del cliente por sobre la negociación del contrato
 Respuesta al cambio por sobre el seguimiento de un plan
 Devops adopta y extiende los principios ágiles y los aplica a toda la organización, no sólo al proceso
de desarrollo.
 Devops tiene implicaciones culturales
 Más allá de Agile y un enfoque que es más amplio que la velocidad de entrega.

Utilidad e Inutilidad de diferentes métodos para itSM
ITSM apoya la disponibilidad continua y el mantenimiento de los servicios para asegurar la entrega de
valor y los resultados deseados del servicio
Procesos tales como:
 Gestión de Incidentes y Problemas
 Disponibilidad y gestión de la continuidad del servicio
 Gestión de Niveles de Servicio
 Gestión de proveedores
 Mejora continua
La metodología más utilizada es ITIL® que cubre la estrategia de servicio, el diseño del servicio, la
transición del servicio, la operación del servicio y la mejora continua del servicio

Utilidad e Inutilidad de diferentes métodos para itSM
 (Aptitud para el propósito) de un servicio. Si la continuidad del servicio no puede ser mantenida y /
o restaurada de acuerdo con los requisitos del negocio, entonces el negocio no experimentará el
valor que se ha prometido. Sin continuidad la utilidad (aptitud para el propósito) del servicio no
puede ser alcanzada.
 Es necesario pensar en cómo reducir la carga de trabajo de gestión. Es necesario realinear ITSM
para DevOps, creando ITSM ligero que está estrictamente centrado en la continuidad del negocio
con un conjunto de información mínima requerida (MRI). El MRI fijado para cada organización
depende de su negocio.

8 ITIL y DevOps

Uso y utilidad de métodos Lean
LEAN
Busca la maximización del valor del cliente y la minimización de los residuos
Residuos (waste) en el contexto de Lean es lo contrario de valor
Cinco principios de Lean Thinking:

 Valor
 Flujo de valor (Value Stream)
 Flujo (Flow)
 Pull (Jalar)
 Perfección

Uso y utilidad de métodos Lean
 Estas ideas, especialmente la búsqueda de la perfección a través de la identificación sistémica y la

eliminación de los residuos, llevó a la definición de Lean como la maximización de customervalue y
minimización de los residuos.
 Los sistemas Lean se enfocan en las partes del sistema que agregan valor al eliminar los desechos
en cualquier otro lugar, ya sea la sobreproducción de algunas partes, productos defectuosos que se
tienen que reconstruir o el tiempo de espera en alguna otra parte del sistema. A partir de esto,
están los conceptos de desarrollo de software Lean IT y Lean, que aplican estos mismos conceptos
a la ingeniería de software ya las operaciones de TI.
Los desechos a eliminar en estas áreas pueden incluir:

 Funciones de software innecesarias
 Retrasos en la comunicación
 Tiempos de respuesta de la aplicación lentos
 Procesos burocráticos dominantes

Value Stream Mapping (VSM)
Concepto Value stream mapping

• Ayuda a identificar los problemas y oportunidades
en el proceso
• Entrega una vista detallada de la descripción del
proceso
Cuando usar
• Para mostrar un cuadro general del proceso de
punta a punta
• Para identificar fuentes de desperdicio
• Para identificar problemas y mejoras
• Para presentar un marco común de discusión
Módulo 1 Adopción de DevOps

VSM
Se muestra la carga del
Problemas en el inicio proceso
del proceso
Se muestran las esperas del

proceso
Se muestra cada
Se muestra el tiempo real del paso del proceso
Se muestra información acerca de los proceso vs el tiempo de valor con su
tiempos del proceso descripciòn
Módulo 1 Adopción de DevOps

9 VSM

EVALUACION [PAGINAS 4 Y 5]
¿Qué principio de DevOps aboga para renovar la forma de prestación de servicios de los equipos ?
a) Automatizar todo lo que pueda
b) Mejora continua
c) Crear con el fin en mente
d) Equipos autónomos multifuncionales

¿Cuál es el objetivo principal de Agile?

a) Crear una cultura de TI de alto rendimiento
b) Crear una cultura de colaboración y automatización
c) Crear hojas de ruta y una forma estructurada de trabajar
d) Satisfacer al cliente

¿Cuáles son las razones clave que debe incluir al crear un caso de negocio para DevOps?
1. Eliminar los desechos rompiendo los silos.
2. Expandir la cartera de productos a los clientes.
3. Aumentar el rendimiento.
4. Impulsar la innovación y la creatividad de sus empleados.
a) 1, 2 y 3
b) 1, 2 y 4
c) 1, 3 y 4
d) 2, 3 y 4

¿Cuál es una de las áreas de habilidad del marco de competencias de DevOps?

a) Análisis de negocio
b) Optimización del valor comercial
c) Entrega continua
d) Mejora Continua

¿Qué aspecto de la fuerza de motivación facilita a los miembros del equipo para actuar más oportuna
y eficazmente?
a) Autonomía
b) Dominio
c) Propósito
d) Autonomía y dominio

¿Qué elemento cultural de DevOps requiere que los equipos descarten métodos improductivos e
inventen métodos más optimizados?
a) Mejora Continua
b) Valor
c) Experimentación
d) Armado de Equipos

¿Qué característica puede ayudarle a desarrollar una cultura DevOps en su organización?

a) Equipos multidisciplinarios integrados
b) Departamentos técnicos separados
c) Funciones de especialistas
d) Conflictos de interés con respecto a la responsabilidad

¿En qué fase del método DMAIC se garantiza que las partes interesadas acuerden el alcance de un
problema determinado?
a) Analizar
b) Definir
c) Mejorar
d) Medir

¿Cuál es la responsabilidad de un equipo del sistema de negocio?

a) Los equipos del Sistema de Negocio son de extremo a extremo responsables de su servicio
durante el ciclo de vida.
b) Los equipos del Sistema de Negocio son responsables del correcto desarrollo del servicio.
c) Los equipos del Sistema de Negocios son de extremo a extremo responsables de la salud de
la tecnología necesaria para ejecutar su servicio.
d) Los equipos del Sistema de Negocio son responsables de la satisfacción del negocio y clientes.

¿Cuáles son las pautas arquitectónicas para el uso del micro servicios?
a) Construir una aplicación compuesta por el menor número posible de servicios.
b) Construcción de servicios que sean capaces de entregar valor comercial independiente de
otros servicios.
c) Construcción de servicios con alto acoplamiento y baja cohesión.
d) Construcción de aplicaciones con un gran número de módulos pequeños.

¿Cuáles de los siguientes temas requieren información para configurar un equipo DevOps?
a) Cliente, pila tecnológica, conocimiento
b) Cliente, organización, arquitectura
c) Punto de desacoplamiento, conocimiento, arquitectura
d) Modelo operativo, gobernanza, cliente

¿Cuál es la principal motivación para establecer equipos autónomos dentro de DevOps?

a) Lograr beneficios de economía de escala y reducir los costos para los clientes.
b) Utilizar la limitada capacidad de los profesionales de TI para una colaboración eficaz.
c) Reducir los residuos y centrarse en el valor del usuario final.
d) Fomentar el efecto de aprender de colegas que hacen el mismo trabajo.

Módulo 2
Planificación, Requerimientos y Diseño
Agenda del Curso



 DevOps en la Práctica
 Gestión del Ciclo de vida de Aplicaciones o Servicios
 Plan de Proyecto (Defining Scope) y Gestión Visual (Project Charter & Visual Control)
 Diseño de Infraestructuras y Arquitectura
 Acuerdos y Requerimientos de Nivel de Servicio
 Implementación de una Estrategia de Pruebas: Historia de Usuario, Historia de Pruebas y Historia
de Operaciones
Módulo 2 Planificación, Requerimientos y Diseño 92

Módulo 2
DevOps en la Práctica
En la sección de DevOps en la Práctica el alumno será capaz de:

 Identificar que es DevOps para los sistemas empresariales
 Explicar la meta de DevOps
 Describir el Cuerpo de Conocimiento de DevOps
 Identificar los Roles de los equipos DevOps
 Explicar distintas organizaciones para DevOps
 Explicar los procesos para DevOps
 Identificar los tipos de implantación de DevOps

DevOps para los Sistemas Empresariales
Hay muchos libros sobre DevOps, pero desafortunadamente, la mayoría describe el uso de DevOps
para el desarrollo web y de productos. Hay muy poca información sobre el uso de DevOps para el
sistema empresarial.
Las empresas poseen tanto el Sistema de Compromiso (SoE) como el Sistema de Registro
(SoR).
 El SoE se centra en la velocidad.
 El SoR se centra en la continuidad del negocio.
El problema es cómo el SoR puede adaptarse rápidamente a los cambios en el SoE para mantener la
continuidad del negocio. Gartner lo llama el desafío Bimodal.
El SoR en la mayoría de las empresas está luchando con el uso de aplicaciones / sistemas heredados
y puede ser ayudado con el uso de DevOps que construye procesos alineados por flujo con conceptos
just-in-time (JIT).

DevOps para los Sistemas Empresariales
DevOps no es una sola herramienta, metodología, conjunto de habilidades u organización. DevOps es

un marco que combina todas estas para que las organizaciones establezcan procesos de flujo
continuo que permitan al negocio operar más rápido y reaccionar a los cambios más rápidamente.
DevOps también puede permitir la madurez utilizando el Ciclo Plan-Do-Check-Act de W. E. Deming
DevOps para los Sistemas Empresariales no sólo es una mejora del desarrollo ágil y entrega continua,
sino también la gestión de servicios de TI y gestión de aplicaciones para permitir el crecimiento del
negocio y mantener la continuidad del negocio.

Meta de DevOps
El objetivo de DevOps es establecer procesos de negocio just-in-time (JIT) alineados en flujo. DevOps
tiene como objetivo maximizar los resultados del negocio, aumentar las ventas y la rentabilidad,
mejorar la velocidad del negocio o minimizar los costos operativos al alinear los procesos
empresariales just-in-time (JIT).
DevOps significa establecer la cadena de suministro de servicios de TI en el negocio de la misma
manera que la cadena de suministro para otros productos está incrustada en el negocio. Es un gran
cambio de paradigma desde la entrega de software hasta la prestación de servicios de TI.
Desde una perspectiva de arquitectura, DevOps necesita establecer un sistema de despliegue rápido
automatizado. Hay muchas metodologías y herramientas que pueden ser utilizadas. DevOps no tiene
una plantilla para la implementación; Cada organización tiene que pensar y construir su propio
proceso de DevOps para mejorar el negocio. Por lo tanto la comprensión de los conceptos de DevOps
es importante para el personal para llevar a cabo los procesos de manera eficiente siguiendo los
procesos correctos.

Fuentes de Conocimiento de DevOps
Al implementar DevOps, aquí hay muchas fuentes de conocimiento, metodologías, prácticas y

herramientas para elegir.
DevOps consta de 3 pilares y una base que se describen a continuación.

1. Disciplina Ágil
2. Entrega Continua
3. ITSM
4. TPS (como fundamento)

Disciplina Ágil
Un equipo de desarrollo Agile disciplinado es clave para el éxito de una implementación de DevOps.
Disciplinado Ágil significa:

1. Velocidad Estabilizada
2. Adaptabilidad para el cambio
3. Código libre de error y de alta calidad SIEMPRE.
Un ciclo de lanzamiento más frecuente y más rápido de los servicios de TI para reaccionar ante los
cambios del negocio depende de la velocidad de desarrollo. La calidad del trabajo es el elemento más
importante y esto puede ser apoyado dividiendo el trabajo en pequeñas tareas
El concepto de Ji-Koutei-Kanketsu (JKK) ³, que significa el 100% de la terminación de un artículo,
ayuda a mantener una alta calidad de trabajo. La Definición de Hecho o finalización debe definirse
claramente para todos. El propietario del producto puede cambiar su misión de no sólo la gestión de
atrasos de productos, sino también la planificación de los costos de operación del servicio de TI que
fue hecho por los ingenieros en jefe de Toyota.

Entrega Continua
La entrega continua es la implementación automatizada de los procesos de creación, implementación,

prueba y liberación de aplicaciones.
Un punto clave se centra en las pruebas tales como las pruebas de aceptación y de rendimiento. TPI
NEXT® puede ser útil para mejorar la madurez de este proceso.
Cada organización tendrá diferencias en la implementación de su canalización de despliegue en
función de su flujo de valor para liberar software. Un factor clave de éxito es establecer sólo una
única canalización de despliegue para servicios de TI.

ITSM (Gestión de Servicios de TI)
Como la tecnología es un componente básico de la mayoría de los procesos de negocio, la

disponibilidad continua o alta de los servicios de TI es crítica para la supervivencia del negocio en su
conjunto. Esto se logra introduciendo medidas de reducción del riesgo y opciones de recuperación. Al
igual que todos los elementos de la administración de servicios de TI, la implementación exitosa del
proceso de continuidad del servicio sólo puede lograrse con el compromiso de la alta dirección y el
apoyo de todos los miembros de la organización. El mantenimiento continuo de la capacidad de
recuperación es esencial si se desea mantener la eficacia. La continuidad del servicio es una parte
esencial de la garantía (aptitud para el propósito) de un servicio. Si la continuidad del servicio no
puede ser mantenida y / o restaurada de acuerdo con los requisitos del negocio, entonces el negocio
no experimentará el valor que se ha prometido. Sin continuidad la utilidad (aptitud para el propósito)
del servicio no puede ser alcanzada.
Las mejores prácticas de gestión de servicios de TI (ITSM) tradicionales, como ITIL®, parecen
pesadas y no son adecuadas para los procesos rápidos de DevOps. Es necesario pensar en cómo
reducir la carga de trabajo de gestión.
Es necesario realinear ITSM para DevOps, creando ITSM ligero que está estrictamente centrado en la
continuidad del negocio con un conjunto de información mínima requerida (MRI). El MRI fijado para
cada organización depende de su negocio.

TPS (Lean) concepto de fundación
La creación de una cadena de suministro de servicios de TI alineada es difícil porque hay muchos
elementos y es necesario cambiar su mentalidad del ciclo de desarrollo existente familiar y sus
metodologías.
Los conceptos de TPS, que incluye JIT y automatización, pueden ayudar.
JIT significa construir una cadena de suministro con flujo de una pieza. Y la automatización significa
automatizar todo lo posible y detener todo el proceso cuando se produce un defecto. El proceso debe
ser diseñado y el personal educado para los dos conceptos anteriores.
La otra cuestión clave es el ciclo de gestión de Desarrollo y Operación. Esto necesita ser cambiado
para trabajar de una manera ágil incluyendo la sincronización entre el desarrollo y la operación sobre
una base semanal o diaria.

Cuerpo de Conocimiento de DevOps

Los Roles en DevOps
Se recomienda que un equipo de DevOps esté configurado en su organización para comprometerse

con la continuidad del negocio del servicio de TI.
Es bueno organizar pequeños equipos de DevOps de acuerdo con la "regla de dos pizzas de Amazon",
es decir, un equipo lo suficientemente pequeño para ser alimentado con dos pizzas!
Los equipos DevOps contienen:
• Process Master (Maesto de Procesos)
• Service Master (Service Master)
• DevOps Engineer (Ingeniero DevOps)
• Gatekeeper / Release coordinator (Portero/Coordinador de versiones)
• Reliability Engineer -Optional (Ingeniero de Confiabilidad – Opcional)
• Development team (Equipo de Desarrollo)
• Operation team (Equipo de Operaciones)

Process Master (Maesto de Procesos)
Dirige el equipo y facilita, este papel es el mismo que "Scrum Master" en Scrum. Implementa el
control visual a lo largo de todo el proceso y tiene un fuerte énfasis en establecer un proceso fluido
con flujo de una sola pieza.
Control visual significa "¿Todo el mundo entiende fácilmente la situación simplemente mirando las
tablas sin explicación?" No muestra el estado. Se puede expresar los problemas ocurridos o no.
Experiencia requerida: Scrum Master, Agile Project Leader.

Service Master (Service Master)
Tiene toda la responsabilidad de proporcionar servicios de TI JIT.
Esta función es como el "Product Owner" de Scrum, que gestiona y prioriza las carteras de productos
y la nueva responsabilidad adicional de la planificación de costes para el servicio de TI.
Experiencia requerida: Scrum Product Owner, propietario del servicio.

DevOps Engineer (Ingeniero DevOps)
Tiene la misión de mejorar y mantener el proceso automatizado.

El ingeniero examinará todo el proceso automatizado y las herramientas.
Hay muchas herramientas necesarias en el proceso DevOps.
Experiencia requerida: Desarrollo y Herramientas.

Gatekeeper / Release coordinator (Portero/Coordinador de versiones)
Responsable de monitorear el estado operacional y el progreso de la próxima versión del servicio de

TI. Tomar decisiones de ir / no ir sobre el despliegue de acuerdo a criterios como seguridad,
cumplimiento, requisitos normativos, madurez del equipo de operación y sus vistas de proceso.
Experiencia requerida: Gestión de servicios de TI, Operaciones.

Reliability Engineer -Optional (Ingeniero de Confiabilidad – Opcional)
Supervisar los servicios en el proceso de despliegue y tratar los problemas con el servicio durante su
ejecución.
Supervisa el estado del proceso para asegurar que el equipo de desarrollo esté siguiendo
estrictamente las reglas de CI (Continuous Integration) y CD (Continuous Delivery).
Supervisar y administrar el flujo de tuberías de construcción complejas.
Tenga una misión para mejorar el proceso de la prueba.
Experiencia requerida: Pruebas, Herramientas, Garantía de calidad.

Development Team (Equipo de Desarrollo)
Uno de los factores clave de éxito para DevOps es la construcción de un equipo ágil disciplinado. Los
equipos ágiles disciplinados se comprometen a cumplir con los planes de lanzamiento y la calidad con
un ritmo sostenible.
Experiencia requerida: Desarrollo, Ágil.

Operation team (Equipo de Operaciones)
Adoptar ITSM ligero y apoyar el diseño, implementación, operación y mejora de estos servicios dentro
del contexto de una estrategia global.
Utilizar "* KAIZEN Advance" ⁷ que es una práctica de KAIZEN en TPS.
Experiencia requerida: Operaciones, KAIZEN.

Organización de DevOps
Es útil organizar el equipo de DevOps en una oficina de administración de servicios para dar soporte
al maestro de servicio.
Hay dos tipos de estructura organizativa recomendadas:
1. Organización plana para una organización pequeña.

2. Organización de matrices para organizaciones grandes y complejas.

Organización plana
Esta es la estructura básica para un equipo pequeño.

Organización matricial
Agrupando expertos y asignándolos a cada uno de los maestros de servicio como un equipo.
La idea para esta organización matricial vino del Jefe-Ingeniero en TOYOTA.

Procesos DevOps
Para crear procesos fluidos, JKK es el método más efectivo para guiar el comportamiento del equipo
de DevOps.
JKK es una forma de trabajar con calidad que significa una comprensión clara de los objetivos, la
comprensión de la forma correcta de trabajar, conseguir el trabajo correcto para completar el 100% y
luego mantener la calidad necesaria sin inspecciones.
Estrategia y planificación empresarial

Marketing y ventas
Administración
Planificación de proyectos
Requisitos y diseño
Desarrollo
Despliegue
Operación
Mantenimiento
Servicio al cliente
Fin de la vida

Estrategia y planificación empresarial
El servicio de TI tiene una estrecha relación con la estrategia y el plan de negocio. El maestro de
servicio debe asistir a las sesiones de planificación de negocios y hacer recomendaciones sobre cómo
obtener ventajas empresariales de los servicios de TI.

Marketing y ventas
El maestro de servicio debe discutir con el negocio cómo obtener ventajas de los servicios de TI. El
maestro de servicio identifica a los clientes de los servicios de TI, reúne los requisitos con valor
comercial y acepta un plazo.

Administración
El maestro de proceso acepta cómo visualizar todo el proceso. Un método es usar Obeya que se
puede configurar para todo el proceso.
Obeya es una sala de guerra que tiene dos propósitos: la gestión de la información y la toma de
decisiones sobre el terreno. Hay muchas herramientas de gestión visual en ella.
Los miembros del equipo pueden ver rápidamente dónde están en cada aspecto del programa.
Cuando el equipo multifuncional trabaja en conjunto, el sistema Obeya permite una toma de
decisiones rápida y precisa, mejora la comunicación, mantiene la alineación, acelera la recolección de
información y crea un importante sentido de integración del equipo.

Planificación de proyectos
El maestro de servicio organiza la oficina de gestión de servicios (SMO) y define reglas básicas para el
equipo.
El maestro de servicio crea la visón, el objetivo y el valor del proyecto y, a continuación, reúne a los
miembros del equipo DevOps.
La infraestructura de tiempo de ejecución definida en esta etapa. Se diseña un mapa de flujo de valor
de todo el proceso.

Requisitos y diseño
El maestro de servicio define los atrasos y las prioridades del producto. El equipo de DevOps utiliza
los atrasos de productos para definir historias
 Historia del usuario: rol, función, valor / razón comercial y condiciones de operación.
 Historia de prueba: casos de prueba de aceptación y criterios de aceptación del servicio.
 Historia de la operación: establecer las prioridades de los servicios de TI y las condiciones de
operación para la continuidad del negocio. Crear acuerdos de nivel de servicio y de nivel operativo.
El ingeniero de DevOps y el equipo de operaciones definen la infraestructura de transición, prueba y

desarrollo.
El equipo de desarrollo también crea planes de liberación e iteración.
El gatekeeper estudia el cumplimiento y los requisitos reglamentarios para los servicios de TI.
El ingeniero de confiabilidad define la metodología de prueba y casos de prueba.

Desarrollo
Scrum es la metodología más aplicable en esta etapa.

El equipo de desarrollo debe comprometerse a liberar los planes y luego trabajar con un enfoque ágil
disciplinado.
El período de cada iteración (sprint) se acuerda de acuerdo con la necesidad del negocio.
Desde el punto de vista de la calidad, las prácticas de XP (programación extrema) como la
programación en pares, TDD, Refactoring y 10 minutos de compilación son efectivas.

Despliegue
Después de completar la integración continua, el proceso automatizado comienza para la prueba de

aceptación, prueba de rendimiento y despliegue.
El ingeniero DevOps debe construir la única tubería de despliegue automatizada como un flujo de una
sola pieza.
El ingeniero de confiabilidad y el ingeniero de DevOps colaboran para mejorar el proceso de pruebas.
El gatekeeper monitorea el progreso a lo largo del proceso y toma la decisión de ir / no ir.
El equipo de operaciones estudia cómo mantener la continuidad del negocio.

Operación
El equipo de operaciones es responsable de monitorear el estado de los servicios de TI durante la

operación usando un proceso ITSM de peso ligero.
Mantener los servicios vitales operativos en caso de un desastre es fundamental.
El equipo debe involucrar al ingeniero de fiabilidad y prestar atención a dos parámetros clave, objetivo
de punto de recuperación y objetivo de tiempo de recuperación.

Mantenimiento
El maestro de servicio y el ingeniero de confiabilidad deciden si aprueban las actividades de

mantenimiento.
Si se aprueban, se agregan a la cartera de productos como solicitudes de cambio

Servicio al cliente
El maestro de servicio y el ingeniero de confiabilidad son responsables de recolectar la

retroalimentación del cliente, tales como, problemas operacionales incluyendo la experiencia del
usuario y problemas de calidad.
Si se aprueban, estos elementos se agregan a la cartera de productos como solicitudes de cambio.

Fin de la vida
El maestro de servicio decide el final de la vida del servicio de TI, incluyendo las condiciones para
cuando y cómo sucederá.
El siguiente diagrama muestra una configuración de muestra de DevOps.

Configuración para DevOps

Configuración para ITSM liviano (light-weight ITSM)

Implantación DevOps
Existen 3 tipos de implementación de DevOps que dependen del modelo de negocio de la empresa.
Manera de TOYOTA: (Complejo y Avanzado)
Colaboración: (Estándar)
Entrega continua: (Básica)

Manera de TOYOTA: (Complejo y Avanzado)
Se centra en servicios estratégicos de TI y da una ventaja estratégica para el negocio.

Es dirigido por el dueño del negocio o el amo del servicio.
Es preferible implementar una organización matricial en una gran empresa y mantener una estrecha
relación entre la estrategia de TI y la estrategia empresarial.
Esta estructura es la más adecuada para los proveedores de servicios de TI.

Colaboración: (Estándar)
Se centra en brindar servicios de TI rápidos y frecuentes y un funcionamiento confiable y es dirigido

por el maestro de servicio.
Es más adecuado para SoE y SoR.

Entrega continua: (Básica)
Se centra en las versiones rápidas y frecuentes de software y es dirigida por el propietario del
producto.
Es más adecuado para los proveedores de productos digitales.

1 BARRERAS PARA DEVOPS

Módulo 2
Gestión del Ciclo de vida de Aplicaciones o Servicios
En la sección de Gestión del Ciclo de vida de Aplicaciones o Servicios el alumno será capaz de:
 explicar cómo DevOps añade valor a la Gestión moderna del Ciclo de Vida de las Aplicaciones
 explicar cómo DevOps mejora la experiencia del cliente cuando se usa para la Gestión del Ciclo de
Vida del Servicio

Aplicaciones y Servicios
Aplicación Servicio
• Gestión del ciclo de • Gestión del ciclo de
vida vida
• Centrarse en el • Centrarse en la
desarrollo de la preparación para la
aplicación prestación de servicios
• El funcionamiento y el durante el desarrollo
mantenimiento de la de la aplicación
aplicación es un ciclo • La prestación de
del ciclo de vida de la servicios tiene su
aplicación que entrega propio ciclo de vida:
el servicio estrategia, diseño,
transición, operación,
mejora

DevOps y las Aplicaciones
DevOps agrega valor a la gestión del ciclo de vida de aplicaciones moderna

 El punto de vista, la meta y el valor del proyecto se acuerdan al comienzo
 Se diseña un mapa de flujo de valor de todo el proceso
 Se utiliza un proceso automatizado para la prueba de aceptación, la prueba de rendimiento y la
implementación
 Se debería considera la posibilidad de tomar los métodos de DevOps en los procesos de negocio
para que puedan convertirse en igual de eficaz y eficiente

DevOps y los Servicios
DevOps mejora la experiencia del cliente cuando se utiliza para la gestión del ciclo de vida del servicio
 Realinear ITSM para DevOps, creando una ITSM ligera que se centra estrictamente en la
continuidad del negocio con un conjunto de información mínima requerida
 El dueño del servicio y el gestor de continuidad son responsables de recolectar la retroalimentación
del cliente para aumentar el valor para ellos, por ejemplo, problemas operativos, experiencia del
usuario y problemas de calidad. Si se aprueban, estos elementos se agregan al Product Backlog
como solicitudes de cambio

ACTIVIDADES [PAGINA 6]
2 PRINCIPIOS PARA DEVOPS

Módulo 2
Project Charter & Visual Control
En la sección de Plan de Proyecto (Defining Scope) y Gestión Visual el alumno será capaz de:
 explicar cómo se determina el ámbito de un proyecto DevOps
 explicar por qué la Gestión Visual de un proyecto DevOps facilita las prácticas

Determinación del alcance de un proyecto DevOps
El Service Master (u otro similar) debe cumplir el siguiente rol en la definición del alcance:
 Asiste a la planificación de negocio para entender las metas del negocio y recomienda cómo utilizar
los servicios de TI para alcanzar los objetivos
 Crea la visón, la meta y el valor del proyecto, y luego reúne a los miembros del equipo DevOps
 Identifica a los clientes de los servicios de TI, reúne los requisitos con valor comercial y acuerda un
marco de tiempo

La facilitación que Control Visual permite sobre un proyecto DevOps
Los gerentes, los administradores, el personal de ventas, los diseñadores, los desarrolladores, los
operadores y el personal de soporte al cliente son un equipo y comparten toda la información
comercial en las juntas visuales
Control visual significa "¿Todo el mundo entiende fácilmente la situación simplemente mirando las
tablas sin explicaciones?"
Permite ver rápidamente el progreso y la identificación de problemas

Módulo 2
Infraestructura y Diseño de Arquitectura
En la sección de Diseño de Infraestructuras y Arquitectura el alumno será capaz de:

 explicar cómo DevOps cambia o influye en el diseño de infraestructuras y arquitecturas TI
 explicar por qué Computación en la nube y técnicas de virtualización facilitan la incorporación de
DevOps

DevOps cambia/influencia el diseño de la infraestructura y arquitectura de TI
 El objetivo de DevOps es que todos los entornos de prueba (incluidos los entornos de integración
continua) sean productivos, sobre todo en la forma en que se administran.
 Un entorno son todos los recursos que su aplicación necesita para trabajar y su configuración. Los
siguientes atributos describen el entorno:
La configuración de hardware de los servidores que forman el entorno (como el número y el
tipo de CPUs, la cantidad de memoria, los husos, las NIC, etc.) y la infraestructura de red que
las conecta
La configuración del sistema operativo y del middleware (como los sistemas de mensajería, los
servidores de aplicaciones y web, los servidores de bases de datos) necesarios para admitir las
aplicaciones que se ejecutarán en él

 El término general infraestructura representa todos los entornos de su organización, junto con los
servicios que los soportan, como servidores DNS, firewalls, routers, repositorios de control de
versiones, almacenamiento, aplicaciones de supervisión, servidores de correo, etc. De hecho, la
frontera entre el entorno de una aplicación y el resto de la infraestructura de su organización puede
variar desde muy claramente definido (en el caso del software embebido, por ejemplo) hasta muy
difuso (en el caso de las arquitecturas orientadas al servicio, compartida por las aplicaciones).
 Esta combinación de aprovisionamiento automatizado y mantenimiento autonómico garantiza que
la infraestructura se pueda reconstruir en un tiempo predecible en caso de fallo.

3 AUTOMATIZACION

Los equipos de desarrollo de aplicaciones y gestión de infraestructuras colaboran en todos los

aspectos de la gestión y el despliegue del entorno desde el inicio del proyecto
 Utilizar técnicas ágiles para gestionar la infraestructura, por ejemplo, Aprovisionamiento
automatizado y mantenimiento autonómico
 Prueba en un entorno de producción como para detectar problemas temprano
 Planificación de continuidad de servicio
 Gestión del cambio para la infraestructura

4 IMPLANTANCION DE UNA CULTURA DEVOPS

Punto de Desacoplamiento (Decoupling)
El punto de desacople (o desacoplamiento) es el que permite separar las responsabilidades de los

equipos DevOps del equipo de Plataforma

5 PUNTO DE DESACOPLAMIENTO

Cloud Computing y Virtualización facilitan DevOps
 En general, la virtualización es una técnica que agrega una capa de abstracción encima de uno o
más recursos de la computadora. Nos enfocaremos principalmente en la virtualización de
plataformas.
 La virtualización de plataformas significa simular un sistema de computadora entero para ejecutar
múltiples instancias de sistemas operativos simultáneamente en una sola máquina física.
 En esta configuración, hay un monitor de máquina virtual (VMM), o hipervisor, que tiene control
total de los recursos de hardware de la máquina física. Los sistemas operativos invitados se
ejecutan en máquinas virtuales, que son administradas por el VMM.
 La virtualización del entorno implica simular una o más máquinas virtuales, así como las conexiones
de red entre ellas.

 La virtualización fue originalmente desarrollada por IBM en la década de 1960 como una alternativa
a la creación de un sistema operativo multitarea de tiempo compartido. La principal aplicación para
la tecnología de virtualización es la consolidación de servidores. De hecho, hubo un período
 IBM evitó recomendar su familia VM a sus clientes, ya que se traduciría en menores ventas de
hardware. Sin embargo, hay muchas otras aplicaciones de esta poderosa tecnología. Se puede
utilizar en una amplia gama de situaciones, como la simulación de sistemas informáticos históricos
en hardware moderno (una práctica común en la comunidad de retro juegos), o como un
mecanismo para apoyar la recuperación de desastres,
 O como parte de un sistema de gestión de configuración para soportar la implementación del
software.
 La característica definitoria del cloud computing es que los recursos informáticos que usa, como
CPU, memoria, almacenamiento, etc., pueden expandirse y contraerse para satisfacer sus
necesidades, y sólo paga por lo que utiliza. La computación en nube puede referirse tanto a los
servicios de software como a los entornos de hardware y software en los que se ejecutan.

Virtualización
 Rápido aprovisionamiento de entornos
 Reducir el tiempo de implementación del software
 Más fácil de ofrecer infraestructura "como servicio"
 Normalización de hardware
Computación en la nube
 Acceso rápido, fácilmente escalable
 Desplegar en una pila completamente estandarizada - no hay necesidad de preocuparse por la
configuración o el mantenimiento de pruebas, entornos o entornos de producción o imágenes de
máquinas virtuales

6 ADOPTANDO CLOUD EN DEVOPS

Módulo 2
SLR y SLA
En la sección de Acuerdos y Requerimientos de Nivel de Servicio el alumno será capaz de:

 explicar cómo DevOps cambia los Requisitos de Nivel de Servicio (SLR) y los Acuerdos de Nivel de
Servicio (SLA)

DevOps cambia los SLR y los SLA
Las historias se utilizan para recopilar, definir y priorizar los requisitos de nivel de servicio y los
acuerdos de nivel de servicio

DevOps cambia los SLR y los SLA
El equipo de DevOps utiliza lhistorias para documentar requisitos y acuerdos de nivel de servicio:
 Historia del usuario: rol, función, valor / razón comercial y condiciones de operación.
 Historia de prueba: casos de prueba de aceptación y criterios de aceptación del servicio.
 Historia de la operación: establecer las prioridades de los servicios de TI y las condiciones
de operación para la continuidad del negocio. Crear acuerdos de nivel de servicio y de nivel
operativo.

7 HISTORIAS PARA SLR Y SLA

Módulo 2
Implementación de la Estrategia de Pruebas
En la sección de Implementación de una Estrategia de Pruebas: Historia de Usuario, Historia de

Pruebas y Historia de Operaciones el alumno será capaz de:
 explicar por qué y cómo debe ser modificada la Estrategia de Pruebas cuando se hace la transición
a DevOps
 analizar y comprobar la integridad de las Historias de Usuario, de Pruebas y de Operaciones

La estrategia de pruebas debe ser ajustada para DevOps
 La prueba es una actividad multifuncional que involucra a todo el equipo, y debe hacerse
continuamente desde el inicio del proyecto.
 Se debe lograr calidad al escribir pruebas automatizadas en múltiples niveles (unidad, componente
y aceptación) y ejecutarlos como parte del pipeline de despliegue, que se activa cada vez que se
realiza un cambio en su aplicación, su configuración o la pila de entorno y software
 Las pruebas manuales son también una parte esencial de la calidad de la construcción: las pruebas
de usabilidad y las pruebas exploratorias deben realizarse continuamente durante todo el proyecto.
 Construir calidad también significa trabajar constantemente para mejorar su estrategia de pruebas
automatizadas.

 En nuestro proyecto ideal, los probadores colaboran con desarrolladores y usuarios para escribir
pruebas automatizadas desde el inicio del proyecto. Estas pruebas se escriben antes de que los
desarrolladores comiencen a trabajar en las características que prueban. En conjunto, estas
pruebas forman una especificación ejecutable del comportamiento del sistema, y cuando pasan,
demuestran que la funcionalidad requerida por el cliente se ha implementado completa y
correctamente.
 El conjunto de pruebas automatizado es administrado por el sistema de configuración cada vez que
se hace un cambio en la aplicación-lo que significa que también sirve como un conjunto de pruebas
de regresión.
 Las pruebas de aceptación son fundamentales en un entorno ágil porque responden a las
preguntas "¿Cómo sé cuando termino?" Para los desarrolladores y "¿Conseguí lo que quería para
los usuarios?"

8 PRUEBAS DE ACEPTACION

Pruebas automatizadas y manuales

 Automatizado, por ejemplo: Unidad, componente, sistema, despliegue, aceptación
 Manual, por ejemplo, exhibición, usabilidad, exploratorio
Pruebas funcionales y no funcionales
Las pruebas son continuas desde el inicio del proyecto
La prueba también se activa con cambios en la aplicación, el entorno o la configuración

Completitud con la historias de usuario
 Las pruebas de aceptación deben ser escritas, e idealmente automatizadas, antes de que el
desarrollo comience en una historia. Las pruebas de aceptación, como los criterios de aceptación,
pueden probar todo tipo de atributos del sistema que se está construyendo, incluyendo
funcionalidad, capacidad, usabilidad, seguridad, modificabilidad, disponibilidad, etc.

 En general, para cada historia o requisito hay un solo camino canónico a través de la aplicación en
términos de las acciones que el usuario realizará. Esto se conoce como el camino feliz. Esto se
expresa a menudo con la forma "Dado [algunas características importantes del estado del sistema
cuando comienza la prueba], cuando [el usuario realiza un conjunto de acciones], entonces
[algunas características importantes del nuevo estado del sistema] . Esto a veces se denomina el
modelo "dado-cuando-entonces" para las pruebas.
 Sin embargo, cualquier caso de uso, en todos los sistemas, excepto el más simple, permitirá
variaciones en el estado inicial, las acciones a realizar y el estado final de la aplicación. A veces,
estas variaciones constituyen casos de uso distintos, que se conocen entonces como caminos
alternos. En otros casos, deben causar condiciones de error, resultando en lo que se denomina
caminos tristes.

Las pruebas muestran cuándo la historia ha llegado a la etapa de 'hecho' para los desarrolladores y
'¿Conseguí lo que quería?' para los usuarios
Historias de usuarios - se pueden probar usando el camino feliz - 'dado x, cuando y, entonces z'
Historias de prueba - Principios INVEST - Independiente, Negociable, Valiosa, Estimable, Small y
Testeable, con criterios de aceptación
Historias de operaciones: compruebe que el despliegue funcionó

EVALUACION [PAGINA 7]
¿Cuál de los siguientes es mas valorado por Scrum?

a) Negociación de contratos, procesos y herramientas, respuesta al cambio, colaboración con el
cliente
b) Documentación integral, software que funciona, procesos y herramientas, respuesta al
cambio
c) Procesos y herramientas, documentación integral, negociación de contratos, seguimiento de
un plan
d) Individuos e interacciones, software que funciona, colaboración con el cliente, respuesta al
cambio

¿Cuáles de los siguientes son ocho tipos de desperdicios?

a) Transporte, movimiento, inventario, procesamiento, espera, sobreproducción, defectos,
habilidades no utilizadas
b) Transporte, Inventario, Procesamiento, Espera, Sobreproducción, Defectos, Habilidades No
Utilizadas, Calidad Extra
c) Transporte, movimiento, inventario, sobreprocesamiento, espera, sobreproducción, defectos,
habilidades no utilizadas
d) Transporte, movimiento, inventario, sobreprocesamiento, horas extras, sobreproducción,
defectos, habilidades no utilizadas

¿Qué es lo correcto en un contexto impulsado por valor?

a) Los recursos y el tiempo son fijos y se estima la funcionalidad.
b) Los recursos y el tiempo son estimados y la funcionalidad es fija.
c) El tiempo y la funcionalidad son fijos y los recursos son estimados.
d) La calidad es fija y se calculan los recursos, el tiempo y la funcionalidad.

Módulo 3
Desarrollo y Despliegue
Agenda del Curso



 Entrega e Integración Continuas
 Pipeline de Despliegue
 Despliegue Continuo
 Kotei-Kanketsu, Ritmo, Work-in-Progress (WIP) y Flujo de una pieza
 Automatización, Herramientas y Pruebas (Testing)
Módulo 3 Desarrollo y Despliegue 176

Módulo 3
Entrega e Integración Continuas
En la sección de Entrega e Integración Continuas el alumno será capaz de:

 explicar por qué la Entrega Continua es esencial para un DevOps efectivo
 analizar cómo integrar la Entrega Continua en un escenario
 analizar cómo resolver los problemas de Entrega Continua en un escenario
 explicar por qué la Integración Continua es esencial para un DevOps efectivo
 analizar cómo conseguir la Integración Continua en un escenario, con equipo distribuido o con un
control de versiones distribuido
 analizar cómo resolver problemas en un escenario de Integración Continua

Entrega e Integración continuos

La entrega continua es esencial para un DevOps efectivo
 La entrega continua es la implementación automatizada de los procesos de creación,

implementación, prueba y liberación de aplicaciones
 Garantiza el rendimiento (entrega rápida) y la conformidad (a los requisitos)
 La entrega rápida permite a los usuarios comenzar a usar el software rápidamente para darse
cuenta de su valor y proporcionar retroalimentación
 Los lanzamientos de mantenimiento permiten que la prestación de servicios sea tratada de la
misma manera
 Esencial para permitir la integración continua

La entrega continua es esencial para un DevOps efectivo
 Utilizando estas prácticas, incluso las grandes organizaciones con aplicaciones complejas pueden
entregar nuevas versiones de su software de forma rápida y confiable. Eso significa no sólo que las
empresas pueden obtener un retorno más rápido de su inversión, sino que pueden hacerlo con
riesgos reducidos y sin incurrir en el costo de oportunidad de ciclos de desarrollo largos, o peor,
entregando software que no es adecuado para el propósito.
 Para utilizar una analogía con la fabricación lean, el software que no se está entregando con
frecuencia es como el inventario almacenado en un almacén. Le ha costado dinero fabricar, pero
no le está haciendo dinero-de hecho, le está costando dinero para almacenarlo.

Integrando Entrega Continua
 Revisar la situación actual

 Escoger el área de enfoque que es inmadura
basada en beneficios.
 Acordar criterios de aceptación
 Planificar e implementar.
 Considerar la prueba de concepto en un
área pequeña
 Revisión de los criterios
 Repetir para otras áreas inmaduras

1 ENTREGA CONTINUA


2 ANALISIS DE MADUREZ

El modelo de madurez puede servir de guía para ayudar a lograr resultados.

Como siempre, se debe aplicar el ciclo de Deming: planifique, haga, compruebe, actúe.
1. Utilice el modelo para clasificar la configuración de la organización y determinar la madurez
de administración. Diferentes partes de su organización logran diferentes niveles en cada
una de las diferentes categorías.
2. Elija un área para enfocarse donde su inmadurez es especialmente dolorosa. El mapeo de
la cadena de valor le ayudará a identificar áreas que necesitan mejoras. Decidir qué
mejoras tienen sentido para su organización, estimar sus costos y beneficios, y priorizar.
Definir criterios de aceptación para especificar los resultados que espera y cómo se
medirán, de modo que pueda decidir si los cambios fueron satisfactorios.

3. Implementar los cambios. Crear un plan de implementación. Comenzar con una prueba de
concepto seleccionando una parte de su organización que realmente está sufriendo
4. Una vez realizados los cambios, utilice los criterios de aceptación para medir si los cambios
tuvieron el efecto deseado. Realizar una reunión retrospectiva de todos los interesados y
participantes para averiguar qué tan bien se ejecutaron los cambios y dónde están las
áreas potenciales de mejora.
5. Repita estos pasos, basándose en su conocimiento. Desarrollar las mejoras de forma
incremental y distribuirlas en toda la organización.
El cambio organizacional es difícil, y el consejo más importante que se puede ofrecer es
implementar el cambio de forma incremental y medir el impacto a medida que avanza. Si se
intenta pasar del nivel uno al nivel cinco en toda la organización en un solo paso, se fallará.
Cambiar las grandes organizaciones puede llevar varios años.

Resolviendo Problemas de Entrega Continua
Ejemplos de problemas:
 Desarrollos Infrecuentes o con Errores
 Mala calidad de la aplicación
 Proceso de Integración Continua gestionado deficientemente
 Mala gestión de la configuración
Cuando ocurre un problema

 Comprobar los síntomas
 Identificar cómo podrían haber sido detectados antes
 Efectuar Análisis de causa raíz
 Arreglar la causa
 Utilizar la gestión de riesgos según se requiera

3 ESCENARIO DE MEJORA

La integración continua es esencial para un DevOps efectivo
 Construir y probar toda la aplicación en cada cambio

 Mantener el software en un estado de trabajo

La integración continua es esencial para un DevOps efectivo
 La integración continua requiere que cada vez que alguien realice algún cambio, se ejecuta
un conjunto completo de pruebas automatizadas. Crucialmente, si falla el proceso de
construcción o prueba, el equipo de desarrollo detiene lo que está haciendo y corrige el
problema inmediatamente.
 El objetivo de la integración continua es que el software esté en un estado de trabajo todo
el tiempo. La integración continua representa un cambio de paradigma. Sin integración
continua, el software se rompe hasta que alguien demuestre que funciona, por lo general
durante una prueba o etapa de integración. Con la integración continua, el software está
probado para funcionar (asumiendo un conjunto suficientemente completo de pruebas
automatizadas) con cada nuevo cambio, y se sabe el momento en que se rompe y puede
arreglarlo de inmediato. Los equipos que utilizan la integración continua con eficacia son
capaces de entregar software mucho más rápido, y con menos errores, que los equipos que
no lo hacen. Los errores se capturan mucho antes en el proceso de entrega cuando son más
baratos de arreglar, proporcionando ahorros significativos en costos y tiempo. Por lo tanto,
consideramos que es una práctica esencial para los equipos profesionales.

Integración Continua en un escenario distribuido
Herramientas de apoyo a equipos distribuidos

 Sistema de control de versiones distribuido
 Generación automatizada: combinará código de varias fuentes
 Pruebas automatizadas: asegúrese de que la estructura no esté rota; Si es así, quien lo
rompa debe arreglarlo o revertirlo para que otros puedan seguir trabajando
 Liberación y despliegue automatizados (pero prueba localmente antes de confirmar el
código para la versión)
 Las herramientas de comunicación electrónica (IM y VoIP) son esenciales para la
comunicación constante

Resolviendo Problemas de Integración Continua
Compruebe que los requisitos para asegurar la integración continua están en su lugar:
 Comprobar el código regularmente (idealmente dos veces al día)
 Crear una completa suite de pruebas automatizadas
 Mantenga el proceso de construcción y prueba corto
 Gestión de su espacio de trabajo de desarrollo

4 VSM

Resolviendo Problemas de Integración Continua
La integración continua es una práctica, no una herramienta. Requiere un grado de

compromiso y disciplina de su equipo de desarrollo. Necesita que todos verifiquen pequeños
cambios incrementales frecuentemente en la línea principal y convengan en que la tarea de
mayor prioridad del proyecto es corregir cualquier cambio que rompa la aplicación. Si la gente
no adopta la disciplina necesaria para que funcione, sus intentos de integración continua no
conducirán a la mejora en la calidad que usted espera.

Módulo 3
Pipeline de Despliegue
En la sección de Pipeline de Despliegue el alumno será capaz de:

 explicar la lógica de la anatomía de un pipeline de despliegue
 explicar cómo utilizar técnicas de scripting para la construcción (build) y el despliegue

Anatomía de un pipeline de despliegue DevOps
Increasing confidence in build’s production readiness
Environments become more production like
User
acceptance
testing
Commit stage
Complete unit Production
Acceptance
test
test stage
Analysis
Build installers Capacity
testing
Faster feedback

El despliegue de las compilaciones puede ser para probar o para entornos reales. En un nivel
abstracto, una tubería de despliegue es una manifestación automatizada del proceso para obtener el
software desde el control de versiones y dejarlo en manos de sus usuarios. Cada cambio en el
software pasa por un proceso complejo en su camino a ser lanzado. La fase de confirmación afirma
que el sistema funciona a nivel técnico. Compila, pasa un conjunto de pruebas automatizadas
(principalmente a nivel de unidad) y ejecuta el análisis de código.

 Las pruebas de aceptación automatizadas afirman que el sistema funciona a nivel funcional y no
funcional, que responde de manera conductiva a las necesidades de sus usuarios y las
especificaciones del cliente.
 Las pruebas manuales aseguran que el sistema es utilizable y cumple con sus requerimientos,
detectar cualquier defecto que no sea detectado por las pruebas automatizadas y verificar que
proporciona valor a sus usuarios. Estas etapas pueden incluir típicamente entornos de pruebas
exploratorias, entornos de integración y UAT (user acceptance testing).
 La etapa de lanzamiento entrega el sistema a los usuarios, ya sea como software empaquetado o
desplegándolo en un entorno de producción o de puesta en escena (un entorno de ensayo es un
entorno de prueba idéntico al entorno de producción).

Ejemplo de Pipeline y sus movimientos

Ejemplo de Pipeline y sus movimientos

Un pipeline básico

Información de Control del Pipeline

Pipeline para productos con fases

Usando scripts para construir y desplegar
Script: toda la automatización que soporta la creación, prueba, implementación y liberación de

nuestro software
Utilice el proceso de creación y despliegue como guía
 Cada tarea de una secuencia de comandos de creación o despliegue es sencilla
Objetivo final: compartir el mismo mecanismo de implementación entre desarrollo, pruebas y
producción
Los scripts deben ser controlados por versiones, mantenidos, probados y refactorizados, y ser el único
mecanismo que utilice para implementar su software

5 SCRIPTS


Usamos el término “script”/"guión" en un sentido bastante amplio.

Generalmente, con esto queremos decir toda la automatización que nos ayuda a construir, probar,
implementar y liberar nuestro software.
Cuando se aproxima a esa amplia colección de secuencias de comandos desde el final de la
canalización de despliegue, se ve tremendamente complejo.
Sin embargo, cada tarea en una secuencia de comandos de creación o despliegue es simple y el
proceso en sí no es complejo.
Conviene utilizar el proceso de creación y despliegue como una guía para colección de scripts.
Desarrolle sus capacidades de compilación y despliegue automatizadas paso a paso, trabajando a
través de la tubería de despliegue identificando iterativamente y luego automatizando los pasos más
dolorosos.

Mantenga el objetivo final en mente todo el tiempo, es decir, el objetivo de compartir el mismo
mecanismo de implementación entre desarrollo, pruebas y producción, pero no se coloque demasiado
en ese pensamiento al principio de la creación de sus herramientas.
Los scripts son partes de primera clase de su sistema. Deben vivir toda su vida. Deben estar
controlados por versiones, mantenerse, probarse y refactorisarse, y ser el único mecanismo que
utilice para implementar su software.
Muchos equipos tratan su sistema de construcción como una idea posterior; los sistemas de
construcción y despliegue son casi siempre la parte debil cuando se trata de diseño. Como resultado,
estos sistemas mal mantenidos son a menudo la barrera para un proceso de liberación sensible y
repetible, en lugar de su fundamento. Los equipos de entrega deben dedicar tiempo y atención a
obtener correctamente los scripts de creación y despliegue.

Deploy de infraestructura

Deploy de infraestructura

Módulo 3
Despliegue Continuo
En la sección de Despliegue Continuo el alumno será capaz de…

 explicar cómo se deben modificar el plan de versiones y de iteraciones para adaptarse a DevOps
 analizar cómo implementar el Despliegue Continuo en un escenario

Los cambios en los Planes de Iteración y Versión para un DevOps efectivo
Despliegue continuo: despliegue todos los cambios que pasen sus pruebas automatizadas a la
producción
Planes de iteración: se proponen implementar en la primera iteración para probar lo que se puede
hacer y probar la implementación
Crear una estrategia de versión antes de cualquier planificación de la versión y mucho antes de la
primera iteración

Ejemplo de prueba y versión

 A medida que la aplicación crece y se vuelve más compleja, la implementación de despliegue

también.
 Dado que la tubería de despliegue debe modelar su proceso de prueba y liberación, primero debe
determinar la liberación.
 Si bien esto se expresa a menudo en términos de promover las construcciones entre entornos, hay
otros detalles.

En particular, es importante capturar

 ¿Qué etapas debe tener una construcción para ser liberada (por ejemplo, pruebas de integración,
pruebas de aceptación de calidad, pruebas de aceptación de usuarios, etapas, producción)
 ¿Cuáles son las puertas o la aprobación requerida? Para cada puerta, quién tiene la autoridad para
aprobar una construcción que pasa por esa puerta.
El primer despliegue de cualquier aplicación debe ocurrir en la primera iteración cuando muestre sus
primeras historias o requerimientos para el cliente. Elija una o dos historias o requisitos que sean de
alta prioridad pero muy sencillas de entregar en su primera iteración (asumiendo que sus iteraciones
son una o dos semanas y se tiene un equipo pequeño, se debe elegir más si estas condiciones no son
aplicables).
Implementar en producción el entorno (UAT). Uno de los principales objetivos de la primera iteración
de un proyecto es conseguir que las etapas iniciales del despliegue funcione y poder desplegar y
demostrar algo funcionando, no importa cuán pequeño. Esta es una de las muy pocas situaciones en
las que se recomienda priorizar el valor técnico sobre el valor del negocio.

Implementando Despliegue Continuo
 Las personas que realizan la implementación deben participar en la creación del proceso de
implementación
 Registro de Actividades de despliegue
 No borre los archivos antiguos, muévalos
 El despliegue es responsabilidad de todo el equipo
 Tener un período de calentamiento para una nueva implementación
 Fallas rápidas
 No realice cambios directamente en el entorno de producción

Implementando Despliegue Continuo
 La objeción intuitiva al despliegue continuo es que es demasiado arriesgada.

 Las liberaciones más frecuentes conducen a un menor riesgo en la eliminación de cualquier
liberación en particular.
 No puede hacerlo sin automatizar todo el proceso de creación, implementación, prueba y
liberación.
 No puede hacerlo sin un conjunto completo y confiable de pruebas automatizadas.
 No puede hacerlo sin escribir pruebas del sistema que se ejecutan en un entorno de tipo
producción.

Despliegue Verde-Azul

Despliegue Canario

6 ANALISIS DE DESPLIEGUES

Módulo 3
Ji-Kotei-Kanketsu, Ritmo, WIP y Flujo de una pieza
En la sección de Ji-Kotei-Kanketsu, Ritmo, Work-in-Progress (WIP) y Flujo de una pieza el alumno será
capaz de:
 explicar los conceptos Ji-Kotei-Kanketsu, Ritmo, Work-in-Progress (WIP) y Flujo de una pieza
 analizar un escenario buscando un problema al utilizar los conceptos de Ji-KoteiKanketsu, Ritmo,
Work-in-Progress (WIP) y Flujo de una pieza y encontrar una solución adecuada

Ji-Kotei-Kanketsu, Ritmo, Work-in-Progress (WIP) y Flujo de una pieza

JKK
 Clara comprensión de los objetivos, garantizar la alta calidad del trabajo, los defectos nunca pasó
al siguiente proceso, la definición de hecho es vital
Ritmo
 El ritmo en el que el equipo de DevOps trabaja y se despliega a la producción
Trabajo en curso (WIP)
 Reducir el WIP para reducir los cuellos de botella y mejorar el tiempo de ciclo
Flujo de una sola pieza
 Trabajar en un elemento a la vez para completar como un individuo o un equipo, ritmo rápido,
flujo suave

JKK - Toyota - Con este método de acercamiento, que significa "asegurar que no se produzcan
defectos en las líneas y que los elementos defectuosos nunca se pasen al siguiente proceso", se
toman las acciones necesarias para lograr el objetivo de "cero defecto" en todos procesos de
producción.
Un flujo continuo de una sola pieza puede tener lugar en un solo equipo trabajando como una unidad
de punto fuerte, en una sola celda de trabajo (o equipo Scrum), para aplicar varias transformaciones
a trabajos en curso (que se limita a una sola pieza a la vez ).
El equipo hace un pequeño análisis, un poco de diseño, un pequeño construcción, y un poco de
prueba de una vez en ciclos muy cortos.
Limitar la cantidad de WIP que se tiene (en otras palabras, la cantidad de trabajo que ha comenzado
pero aún no se ha completado) es una excelente manera de aumentar el rendimiento en el pipeline
de desarrollo de software.

7 JKK

Problemas en JKK, Ritmo, WIP y Flujo de una pieza y posible solución
Controles útiles:
 ¿Se han pasado los defectos al proceso siguiente?
 ¿Está clara la definición de hecho?
 ¿Hay un ritmo constante para el despliegue?
 ¿Cuánto trabajo en curso?
 ¿Cuántas personas están trabajando en más de un artículo?

Módulo 3
Automatización, Herramientas y Pruebas (Testing)
En la sección de Automatización, Herramientas y Pruebas (Testing) el alumno será capaz de:

 explicar por qué la automatización es importante para un DevOps efectivo
 explicar cómo utilizar las herramientas para facilitar DevOps en general
 explicar cómo utilizar las herramientas para apoyar la mentalidad y la cultura DevOps
 explicar por qué es fundamental que se automaticen las pruebas
 analizar un escenario y escoger la forma correcta de automatizar un test de aceptación

La automatización es importante para un DevOps efectivo
Automatización apoya los

objetivos de DevOps
Simplificando y
eliminando las
Reduciendo Mejorando la
tareas
mano de obra, calidad,
repetitivas que
energía y / o precisión y
pueden estar
materiales exactitud
sujetas a errores
humanos

La automatización es importante para un DevOps efectivo
 La entrega continua y el despliegue continuo libra personal para centrarse en lo que importa.
 Ciclos de retroalimentación automatizados y automatización de la construcción con pruebas
proporcionan confianza adicional y visión del sistemas.
 La instalación de un servidor es la automatización de la configuración y configuración de servidores
individuales.
 La automatización de la infraestructura se logra proporcionando elementos de la infraestructura a
través del tratamiento de código al igual que el resto de su software, con la capacidad de
recuperar negocios a través de copias de seguridad de datos, repositorio de código y recursos de
cálculo.
 Se tienen la opción de invertir en la infraestructura de la nube.
 Las herramientas de automatización de compilación de hoy generalmente especifican cómo se va a
construir el software (qué pasos hay que hacer y en qué orden) y qué dependencias se requieren
(qué otro software necesita estar presente para que la generación tenga éxito).
 Monitoreo - Con el tiempo, usted querrá sintonizar y ajustar su monitoreo y alerta a medida que
aprenda más sobre el verdadero impacto de sus problemas y eventos.

Las herramientas facilitan DevOps
El equipo de DevOps necesita herramientas para hacer su trabajo de manera efectiva:

 Desarrollo de software
 Entorno de desarrollo local
 Control de versiones
 Gestión de artefactos
 Pruebas
 Monitoreo

Las herramientas facilitan DevOps
 Las herramientas de desarrollo de software ayudan con el proceso de programación,

documentación, pruebas y corrección de errores en aplicaciones y servicios.
 Sin restricción a roles específicos, estas herramientas son importantes para cualquier persona que
trabaja en software
 Se deben hacer revisiones regulares de los procesos y herramientas actuales para asegurarse de
que su uso sigue siendo efectivo.
 La automatización y el seguimiento técnico pueden ayudar a identificar procesos y herramientas
que deben eliminarse.
 Esto puede ayudar a prevenir situaciones en las que una herramienta ha estado causando trabajo
adicional para quienes lo usan, y ayudar a identificar y eliminar herramientas que cumplan el
mismo propósito, reduciendo costos y confusión.

Las herramientas soportan la mentalidad y cultura de DevOps
Dirección
Cultura Herramientas
Mentalidad

 La cultura DevOps es una de colaboración entre equipos, organizaciones e industrias. Al desarrollar

soluciones, es importante pensar en su impacto en los equipos y las organizaciones, no sólo las
personas. Las herramientas de Devops tensionan "nosotros" sobre "mí"; Que permiten a los
equipos y organizaciones para construir la comprensión mutua para hacer el trabajo. Su elección
de herramientas es una opción en un lenguaje común. Las herramientas son aceleradores,
aumentando nuestra velocidad impulsando el cambio en función de la cultura y dirección actuales
de una organización. Si bien estas herramientas son una parte importante de un entorno de
devops, es importante enfatizar que mejoran, pero nunca pueden reemplazar, los aspectos
interpersonales y culturales de ese ambiente.

 La forma en que se utilizan las herramientas y la facilidad con que se pueden utilizar influye en la
aceptación y proliferación de aspectos específicos de la cultura.
 Cuando hablamos de herramientas de desarrollo, nos referimos tanto a las propias herramientas
como a la manera de su uso
 Las herramientas no están completamente separadas de los otros tres pilares de DevOpss
efectivos.
 Las herramientas pueden impactar y ser impactadas por la forma en que trabajamos e
interactuamos, y todos estos factores e interacciones deben ser considerados para lograr un
cambio significativo y duradero.

Es importante que la prueba en DevOps se automatice
Pruebas
automatizadas
Prueba manual
Realimentación
Hecho

8 AUTOMATIZACION

 Demasiados proyectos dependen únicamente de pruebas de aceptación manual para verificar que
una pieza de software se ajusta a sus requisitos funcionales y no funcionales.
 Incluso donde existen pruebas automatizadas, a menudo se mantienen mal y se des actualizan y
requieren completar con pruebas manuales extensivas.
 Construir pruebas automatizadas en múltiples niveles (unidad, componente y aceptación) y
ejecutarlos como parte de la tubería de despliegue, que se activa cada vez que se realiza un
cambio en su aplicación, su configuración o la pila de entorno y software

 Las pruebas manuales son también una parte esencial de la calidad de la construcción: las pruebas
de usabilidad y las pruebas exploratorias deben realizarse continuamente durante todo el proyecto.
 Construir calidad también significa trabajar constantemente para mejorar la estrategia de pruebas
automatizadas.
 En muchos proyectos, las pruebas se tratan como una fase distinta realizada por especialistas.
 Un software de alta calidad sólo es posible si las pruebas se convierten en la responsabilidad de
todos los que participan en la entrega de software y se practica desde el comienzo del proyecto y a
lo largo de su vida.
 Las pruebas se ocupan principalmente de establecer bucles de retroalimentación que impulsen el
desarrollo, el diseño y la liberación.
 Las pruebas están fundamentalmente interconectadas con su definición de "hecho", y su estrategia
de pruebas debe centrarse en poder ofrecer esa característica de comprensión por características y
asegurarse de que las pruebas sean omnipresentes a lo largo de su proceso.

Elección de la manera correcta de automatizar un test de aceptación
• Dado
Criterios de
• Cuando
aceptación
• Entonces
• El código utiliza el lenguaje del

Capa de dominio
implementación de
prueba • No hace referencia a elementos de
la interfaz de usuario
• Entiende cómo interactuar con la

Capa del controlador
aplicación para realizar acciones y
de aplicaciones
devolver resultados.

 Las pruebas de aceptación son una etapa crucial en el despliegue del pipeline: Toman equipos de
entrega más allá de la integración continua básica.
 Una vez que haya realizado las pruebas de aceptación automatizadas, se deben probar los criterios
de aceptación, es decir, validar que proporcionan funcionalidad valiosa a los usuarios.
 Una prueba de aceptación individual está destinada a verificar que los criterios de aceptación de
una historia o requisito se han cumplido.
 Los criterios de aceptación vienen en muchas variedades diferentes; pueden ser funcionales o no
funcionales.
 Los criterios de aceptación no funcionales incluyen cosas como capacidad, rendimiento,
modificabilidad, disponibilidad, seguridad, usabilidad, etc.

 El conjunto de pruebas de aceptación en su conjunto verifica que la aplicación entrega el valor de

negocio esperado por el cliente y protege contra regresiones o defectos que rompen funciones
preexistentes de la aplicación.
 Las pruebas de aceptación son orientadas a los negocios, no a los desarrolladores. Ellos prueban
historias enteras a la vez en contra de una versión en ejecución de la aplicación en un entorno
similar a la producción.
 Las pruebas unitarias son una parte esencial de cualquier estrategia de prueba automatizada, pero
por lo general no proporcionan un nivel de confianza lo suficientemente alto como para que la
aplicación pueda ser liberada.
 El objetivo de las pruebas de aceptación es demostrar que la aplicación hace lo que el cliente
quería decir, no que funcione de la manera que sus programadores piensan que debería.
 El costo de una suite de pruebas de aceptación automatizada correctamente creada y mantenida
es mucho menor que la realización de frecuentes aceptaciones manuales y pruebas de regresión, o
la alternativa de liberar software de mala calidad.

¿Qué tipo de tareas se caracterizan por una alta variabilidad y una alta capacidad de análisis?
a) Rutina
b) Manuales
c) Ingeniería
d) No rutinarias

¿Cuál de los siguientes ofrece retroalimentación sobre la calidad externa del software?
a) Resultados de la ejecución automatizada del despliegue
b) Resultados de las pruebas automatizadas de carga
c) Resultados del análisis automatizado de código estático
d) Resultados de las pruebas unitarias automatizadas

¿Cuál es el concepto de subdividir lógicamente y aprovisionar una infraestructura para

Organizaciones?
a) Elasticidad
b) Medición
c) Multitenancy
d) Agrupación de recursos

¿Cuál es el propósito de la “Especificación por Ejemplo” de la técnica de Desarrollo Guiádo por

Comportamiento (Bdd – Behavoir Driven Development ) ¿
a) Definir funcionalidad para probar los criterios de aceptación de la historia de usuario
b) Definir pruebas de bajo nivel tales como pruebas unitarias
c) Escribir software para la historia del usuario
d) Corregir errores y refactorizar el código de software y / o código de prueba

Módulo 4
Operación y Escalado
Agenda del Curso



 Gestión de Datos; Infraestructuras y Entornos; y Componentes y Dependencias
 Gestión de Configuraciones y Control de Versiones
 Cloud e Infraestructuras Estáticas
 Continuidad de Negocio
 Escalado
Módulo 4 Operación y Escalado 253

Módulo 4
Gestión de Datos; Infraestructuras y Entornos; y Componentes y Dependencias
En la sección de Gestión de Datos; Infraestructuras, y Entornos, y Componentes y Dependencias el

alumno será capaz de:
 explicar los problemas que se encuentran al manejar datos de bases de datos en entornos DevOps
 analizar un escenario donde se utiliza una base de datos en un entorno DevOps y dar la mejor
solución al problema
 analizar un escenario e identificar la mejor forma de preparar la infraestructura para el despliegue,
o bien para gestionarla después del despliegue
 analizar un escenario y sugerir estrategias comunes para la gestión de componentes
 explicar cómo gestionar dependencias

Problemas que enfrenta DevOps cuando se gestionan datos en bases de datos
Los datos y su gestión y organización plantean un conjunto particular de problemas para los procesos
de prueba y despliegue por dos razones.
 Primero, el volumen de información que generalmente está involucrado. Los bytes asignados para
codificar el comportamiento de la aplicación -su código fuente e información de configuración-
suelen ser ampliamente superados por el volumen de datos que registran su estado.
 En segundo lugar, el hecho de que el ciclo de vida de los datos de aplicación difiere del de otras
partes del sistema. Es necesario conservar los datos de la aplicación; de hecho, los datos
sobrepasan generalmente las aplicaciones que se utilizaron para crear y acceder a ella.
Es crucial que los datos se conserven y migren durante las nuevas implementaciones o retrocesos de
un sistema.

Problemas que enfrenta DevOps cuando se gestionan datos en bases de datos
 Gran volumen de información

 El ciclo de vida de los datos de aplicación difiere del de otras partes del sistema
 Dificultad para automatizar el proceso de migración de la base de datos
 La gestión de los datos de prueba y el uso de los datos de producción para la prueba pueden ser
problemas

Como entregar la mejor solución a un problema de Base de Datos
 Al igual que con cualquier otro cambio en el sistema, cualquier cambio en cualquier base de datos
utilizada como parte de su proceso de generación, despliegue, prueba y liberación debe ser
gestionado a través de procesos automatizados.
 Esto significa que la inicialización de la base de datos y todas las migraciones necesitan ser
capturadas como scripts y verificadas en el control de versiones.
 Debido a su ciclo de vida, la gestión de los datos presenta una colección de problemas diferentes
de los que hemos discutido en el contexto de la tubería de despliegue.

Éstos son algunos de los principios y prácticas más importantes:

 Versión de su base de datos y utilizar una herramienta como DbDeploy para administrar las
migraciones automáticamente.
 Esforzarse por conservar la compatibilidad hacia delante y hacia atrás con los cambios de
esquema, de modo que pueda separar los problemas de despliegue y migración de datos de los
problemas de implementación de aplicaciones.
 Asegurarse de que las pruebas crean los datos en los que se basan como parte del proceso de
configuración y de que los datos se reparten para garantizar que no afectan a otras pruebas que
podrían estar ejecutándose al mismo tiempo.
 Reservar el intercambio de configuración entre las pruebas sólo para los datos necesarios para que
se inicie la aplicación, y tal vez algunos datos de referencia muy generales.
 Intente utilizar la API pública de la aplicación para configurar el estado correcto para las pruebas
siempre que sea posible.
 En la mayoría de los casos, no utilizar volcados del conjunto de datos de producción para fines de
prueba. Crear conjuntos de datos personalizados seleccionando cuidadosamente un subconjunto
más pequeño de datos de producción, o de pruebas de aceptación o de capacidad.

 Versión de base de datos y utilizar una herramienta para gestionar las migraciones de forma
automática.
 Esforzarse por conservar la compatibilidad hacia adelante y hacia atrás con los cambios de
esquema
 Asegúrese de que las pruebas creen los datos en los que dependen como parte del proceso de
configuración
 Reservar el intercambio de configuración entre las pruebas sólo para los datos necesarios para
iniciar la aplicación
 Intentar utilizar API pública de aplicación para configurar el estado correcto para las pruebas
siempre que sea posible
 En la mayoría de los casos, no utilizar volcados del dataset de producción para propósitos de
prueba. Crear conjuntos de datos personalizados seleccionando cuidadosamente un subconjunto
más pequeño de datos de producción, o de pruebas de aceptación o de capacidad

Identificar la mejor manera para preparar un ambiente para despliegue
Un entorno son todos los recursos que su aplicación necesita para trabajar y su configuración. Los
siguientes atributos describen el entorno:
 La configuración de hardware de los servidores que forman el entorno (como el número y el tipo
de CPUs, la cantidad de memoria, los husos, las NIC, etc.) y la infraestructura de red que los
conecta.
 La configuración de del sistema operativo y del middleware (tales como sistemas de mensajería,
servidores de aplicaciones y web, servidores de bases de datos) necesarios para soportar las
aplicaciones que se ejecutarán dentro de él.

1 APROVISIONAMIENTO DE SERVIDORES

1 APROVISIONAMIENTO DE SERVIDORES

Enfoque holístico para administrar toda la infraestructura, basado en los siguientes principios.
 El estado deseado de su infraestructura debe especificarse mediante una configuración controlada
por versiones.
 La infraestructura debe ser autónoma, es decir, debe corregirse automáticamente al estado
deseado.
 Siempre debe conocer el estado real de su infraestructura a través de la instrumentación y el
monitoreo.

Hay cuatro áreas a considerar al crear una estrategia de monitoreo para su infraestructura y
aplicaciones:
 Instrumentación de sus aplicaciones y su infraestructura para que pueda recopilar los datos que
necesita
 Almacenar los datos para que puedan ser recuperados fácilmente para el análisis
 Creación de cuadros de mando que agregan el Datos y presentarlo en un formato adecuado para
las operaciones y para el negocio
 Configuración de notificaciones para que las personas puedan averiguar sobre los eventos que les
importan

 Enfoque holístico para gestionar toda la infraestructura:

 El estado deseado de su infraestructura debe especificarse mediante una configuración controlada
por versiones
 La infraestructura debe ser autonómica, es decir, debe corregirse automáticamente al estado
deseado
 Siempre debe conocer el estado real de su infraestructura a través de instrumentación y monitoreo

2 PRODUCCION, RESPALDO Y MONITOREO

2 PRODUCCION, RESPALDO Y MONITOREO

La mejor manera para administrar componentes
¿Qué es un componente?
 Este es un término horriblemente sobrecargado en el software, por lo que trataremos de hacer lo
más claro posible lo que queremos decir con él.
 Cuando hablamos de componentes, nos referimos a una estructura de código razonablemente
grande en una aplicación, con una API bien definida, que podría ser intercambiada para otra
implementación.
 Un sistema de software basado en componentes se distingue por el hecho de que la base de
código se divide en partes discretas que proporcionan comportamiento a través de interacciones
bien definidas y limitadas con otros componentes.

Hay varias razones por las que los componentes hacen que el proceso de desarrollo de software sea
más eficiente:
1. Divide el problema en trozos más pequeños y más expresivos.
2. Los componentes a menudo representan diferencias en las tasas de cambio de diferentes partes
del sistema, y tienen diferentes ciclos de vida.
3. Nos animan a diseñar y mantener un software con una delimitación clara de responsabilidades, lo
que a su vez limita el impacto del cambio y facilita la comprensión y el cambio de la base de
código.
4. Pueden proporcionarnos grados adicionales de libertad para optimizar nuestro proceso de
creación y despliegue.

 Aplicación bien diseñada que es susceptible a una construcción componentizada

 Definir un componente
 Organizar equipos por área funcional / grupo de historias en lugar de componentes
 Construir componentes en tuberías y luego pasar a una tubería de integración
 Tener en cuenta las dependencias
 Usar el repositorio de artefactos


3 DEPLOY CON DISTINTAS VERSIONES DE BASE DE DATOS

3 DEPLOY CON DISTINTAS VERSIONES DE BASE DE DATOS

Gestión de Dependencias
Reports
Engine
Portfolio
Settlement
Framework management
Engine Application
Pricing
Library
Engine

Ejemplo:
 La aplicación de gestión de cartera depende de un motor de fijación de precios, un motor de
liquidación y un motor de informes.
 Estos, a su vez, dependen de un marco.
 El mecanismo de fijación de precios depende de una biblioteca de CDS (credit default swap) que
es proporcionada por un tercero (ahora en dificultades).

 En general, nos referimos a un componente más a la izquierda del diagrama como una
dependencia "aguas arriba", y un componente más a la derecha como una dependencia "aguas
abajo".
 Por lo tanto, el motor de precios tiene dos dependencias ascendentes, la biblioteca de precios CDS
y el marco, y una dependencia descendente, la aplicación de gestión de cartera.
 La restricción más importante en estos escenarios es que la aplicación de gestión de cartera sólo
debe construir en contra de una versión del marco.
 En particular, no queremos terminar con una versión de (digamos) el motor de precios construido
contra una versión del framework, y el motor de liquidación construido contra otra versión.
 Este es el clásico problema de la "dependencia del diamante", que es el análogo de tiempo de
construcción del problema de "infierno de dependencia" de tiempo de ejecución.

 Una dependencia se produce cuando una pieza de software depende de otra para construir o
ejecutar.
 En cualquiera de las aplicaciones más triviales, habrá algunas dependencias.
 La mayoría de las aplicaciones de software tienen, como mínimo, una dependencia de su entorno
operativo principal.

4 PIPELINE A PRODUCCION

4 PIPELINE A PRODUCCION

Módulo 4
Gestión de Configuraciones y Control de Versiones
En la sección de Gestión de Configuraciones y Control de Versiones el alumno será capaz de:

 explicar por qué el control de versiones es clave para un DevOps efectivo
 explicar cómo mantener un control de versiones sobre datos, infraestructuras y componentes
 analizar un escenario y sugerir la mejor estrategia para atacar un problema de gestión de
configuraciones

El Control de Versiones es clave de un DevOps efectivo
 Gestión de la configuración se refiere al proceso por el cual todos los artefactos relevantes para su
proyecto, y las relaciones entre ellos, se almacenan, recuperan, identifican de forma única y se
modifican.
 Aunque los sistemas de control de versiones son la herramienta más obvia en la administración de
la configuración, la decisión de usar uno (y cada equipo debe usar uno, no importa cuán pequeño)
es sólo el primer paso en el desarrollo de una estrategia de administración de configuración.
 Los sistemas de control de versiones, también conocidos como control de código fuente, sistemas
de administración de código fuente o sistemas de control de revisiones, son un mecanismo para
mantener múltiples versiones de sus archivos, de modo que al modificar un archivo todavía puede
acceder a las revisiones anteriores.

 También son un mecanismo a través del cual las personas involucradas en la entrega de software
colaboran. Una razón por la que usamos el control de versión de término en preferencia al control
de código fuente es que el control de versión no es sólo para código fuente.
 Cada artefacto relacionado con la creación de su software debe estar bajo control de versiones.
 El objetivo es tener todo lo que pueda cambiar en cualquier momento de la vida del proyecto
almacenado de manera controlada.
 Esto le permite recuperar una instantánea exacta del estado de todo el sistema, desde el entorno
de desarrollo hasta el entorno de producción, en cualquier momento de la historia del proyecto.
 Este nivel de gestión de la configuración garantiza que, siempre que mantenga el repositorio
intacto, siempre podrá recuperar una versión de trabajo del software.

 Mantiene múltiples versiones de archivos para permitir el seguimiento de diferentes versiones y

siempre ser capaz de volver a la versión de trabajo
 Todos los artefactos relacionados con el software deben estar bajo control de versiones
 Fundamental para la colaboración
 Las prácticas de DevOps para reducir el tiempo de ciclo y aumentar la calidad, desde la integración
continua y las pruebas automatizadas hasta las implementaciones de pulsadores, dependen de
tener todo en un repositorio de control de versiones

5 RELEASE CON DOS EQUIPOS

5 RELEASE CON DOS EQUIPOS

Manteniendo Control de Versiones en Datos, Infraestructura y Componentes
 La tubería de despliegue es un paradigma para mover el código desde el check-in a producción de

manera controlada.
 Sin embargo, es sólo uno de los tres grados de libertad con los que tiene que trabajar en sistemas
de software de gran tamaño.
 Además de almacenar código fuente e información de configuración, muchos proyectos también
almacenan imágenes binarias de sus servidores de aplicaciones, compiladores, máquinas virtuales
y otras partes de su cadena de herramientas en el control de versiones.
 Esto es fantásticamente útil, acelerando la creación de nuevos entornos y, lo que es más
importante, asegurando que las configuraciones de base están completamente definidas y que se
sabe que son buenas.
 Simplemente verificando que todo lo que necesita fuera del repositorio de control de versiones
garantiza una plataforma estable para entornos de desarrollo, prueba o incluso de producción.
 Una cosa que no recomendamos que mantenga en el control de versiones es la salida binaria de la
compilación de su aplicación, demasiado grande y recreada.

 Si su sistema crece o tiene componentes de los que dependen varios proyectos, puede considerar
dividir los componentes de sus componentes en tuberías separadas.
 Si lo hace, es importante tener dependencias binarias entre sus pipelines en lugar de las
dependencias de origen.
 Recompilar las dependencias no sólo es menos eficiente; también significa que está creando un
artefacto potencialmente diferente del que ya probó.
 El uso de dependencias binarias puede dificultar el rastreo de una rotura del cambio de código
fuente que lo causó, pero un buen servidor de CI le ayudará con este problema.

Datos
Infraestr
uctura
Compon
entes
Control de Versiones

Mejor estrategia para gestionar problemas de gestión de configuración
Hay tres buenas razones para derivar el código.

 Primero, se puede crear un equipo para liberar una nueva versión de su aplicación. Esto permite a
los desarrolladores continuar trabajando en nuevas características sin afectar la publicación pública
estable. Cuando se encuentran errores, primero se fijan en la rama de liberación pública relevante
y luego los cambios se aplican a la línea principal. Las ramas de lanzamiento nunca se combinan
de nuevo con la línea principal.
 En segundo lugar, cuando se necesita externalizar nueva característica o un refactoring; la rama se
entrega y nunca se funde de vuelta. Sin embargo, es importante reconocer que cada vez que se
terceriza aparece un costo. Ese costo entra en mayor riesgo, y la única manera de minimizar ese
riesgo es ser diligente en asegurar que cualquier rama activa, creada por cualquier razón, se debe
fusionar de nuevo a mainline diaria o con más frecuencia. Sin esto, el proceso ya no puede
considerarse basado en una integración continua.

 Por último, es aceptable crear una versión de corta duración cuando necesite realizar un cambio
grande en la aplicación que no sea posible con cualquiera de los métodos descritos, lo cual es un
escenario extremadamente raro si su base de código está bien estructurada. El único objetivo de
esta rama es conseguir que la base de código llegue a un estado en el que se puedan realizar
cambios adicionales de forma incremental a través de una versión por abstracción.

Problema: la infraestructura de red entre los sitios de desarrollo es lenta y poco fiable
 Crear un repositorio local para el equipo y fusionar los cambios del equipo a la línea principal todos
los días
Problema: Proyecto muy grande con ramas paralelas
 Desarrollar una estrategia de fusión claramente descrita con un servidor de integración continua
independiente para cada una de estas ramas relativamente largas y un pequeño equipo de fusión
dedicado para administrar el proceso
Problema: ramas separadas para cada cliente de un producto y pruebas en un repositorio de control
de versiones separado de su código
 Utilice un repositorio de control de versión común para el código y las pruebas para que puedan
estar claramente vinculados

Módulo 4
Cloud e Infraestructuras Estáticas
En la sección de Cloud e Infraestructuras Estáticas el alumno será capaz de:

 explicar cuándo es o no es necesario migrar a una infraestructura basada en la nube para un
DevOps efectivo
 explicar cómo se debe gestionar la infraestructura basada en la nube en un entorno DevOps

6 CLOUD O NO CLOUD

Ventas de moverse o no a la nube
Moverse a Cloud No moverse a Cloud

• Eliminar la sobrecarga de compra, • Pasar a Cloud o comprar herramientas
instalar y mantener el hardware no hará que DevOps funcione - es más
• Uso flexible de recursos para expandir y que eso
contraer • Inversión en la infraestructura existente
• Evite el bloqueo del proveedor • Crecimiento y querer infraestructura
• Inicio rápido para una nueva propia
organización • Terceros, nivel de servicio y
• Pila estandarizada preocupaciones de seguridad
• Se adapta a muchos principios de • Rendimiento: los servidores de alto
DevOps rendimiento pueden ser más rápidos
que algunos servicios en la nube para la
manipulación de grandes conjuntos de
datos

Administrando infraestructura en la nube para DevOps
Investigue varias opciones para:

 Servicios - infraestructura, plataforma
 Niveles de servicio
 Seguridad, requisitos de cumplimiento
 Flexibilidad
 Seguimiento, presentación de informes
 La infraestructura basada en la nube necesita menos gestión pero no cero

Módulo 4
Continuidad de Negocio
En la sección de Continuidad de Negocio el alumno será capaz de:

 explicar cómo DevOps facilita las prácticas de Continuidad del Negocio

DevOps facilita las prácticas de Continuidad del Negocio
 La empresa posee tanto el Sistema de Compromiso (SoE) como el Sistema de Registro (SoR). El
SoE se centra en la velocidad. El SoR se centra en la continuidad del negocio. El problema es cómo
el SoR puede adaptarse rápidamente a los cambios en el SoE para mantener la continuidad del
negocio.
 DevOps no sólo es una mejora del desarrollo ágil y entrega continua, sino también la gestión de
servicios de TI y gestión de aplicaciones para permitir el crecimiento del negocio y mantener la
continuidad del negocio.
 Como la tecnología es un componente básico de la mayoría de los procesos de negocio, la
disponibilidad continua o alta de los servicios de TI es crítica para la supervivencia del negocio en
su conjunto. Esto se logra introduciendo medidas de reducción del riesgo y opciones de
recuperación.

 Al igual que todos los elementos de la administración de servicios de TI, la implementación exitosa
del proceso de continuidad del servicio sólo puede lograrse con el compromiso de la alta dirección
y el apoyo de todos los miembros de la organización.
 El mantenimiento continuo de la capacidad de recuperación es esencial para que siga siendo
eficaz. La continuidad del servicio es una parte esencial de la garantía (aptitud para el propósito)
de un servicio.
 Si la continuidad del servicio no puede ser mantenida y / o restaurada de acuerdo con los
requisitos del negocio, entonces el negocio no experimentará el valor que se ha prometido. Sin
continuidad la utilidad (aptitud para el propósito) del servicio no puede ser alcanzada.
 Las mejores prácticas de gestión de servicios de TI (ITSM) tradicionales, como ITIL, parecen
pesadas y no son adecuadas para los procesos rápidos de DevOps. Es necesario pensar en cómo
reducir la carga de trabajo de gestión.
 Es necesario realinear ITSM para DevOps, creando ITSM ligero que está estrictamente centrado en
la continuidad del negocio con un conjunto de información mínima requerida (MRI). El MRI fijado
para cada organización depende de su negocio.

La alta disponibilidad de servicios de TI es crítica para la supervivencia del negocio en su conjunto

Utilizar medidas de reducción del riesgo y opciones de recuperación
El mantenimiento continuo de la capacidad de recuperación es esencial

Módulo 4
Escalado
En la sección de Escalado el alumno será capaz de:

 analizar un escenario y explicar si es necesario realizar un escalado incremental o
 una reducción (scale-up or scale-down) en esa situación y por qué e identificar la mejor forma de
hacerlo.
 analizar un escenario buscando qué ha ido mal en una situación de escalado e identificar una
manera adecuada de resolver el problema
 explicar cómo las políticas sociales y de contratación apoyan el escalado de DevOps

Escalado
Escalado es sobre la evolución, el crecimiento y el avance de la organización como un todo a lo largo

de todo su ciclo de vida
Escalado con éxito es el arte y la ciencia de darse cuenta de cuándo y cómo cambiar de dirección
como sea necesario para navegar el entorno en constante cambio.

Escalado
 DevOps es fundamental para desarrollar fuerza, equilibrio y agilidad dentro de una gran empresa
como lo es en organizaciones más pequeñas.
 Es la aplicación o aplicación de los principios que difieren en las organizaciones más grandes, no
los principios mismos.
 Los investigadores descubrieron que los principios culturales de DevOps podrían aplicarse a
organizaciones de cualquier tamaño y que los principios técnicos como la entrega continua y el
mejoramiento de los procesos de implementación podrían aplicarse a cualquier proyecto de
software bien diseñado y con adecuada arquitectura, incluso a los antiguos.
 Un nuevo proyecto basado en microprocesos no va a tener éxito porque es nuevo y tiene micro
servicios, tiene que estar bien diseñado, comprobable y fácilmente desplegable.
 Estos principios se aplican a todos los proyectos de software, antiguos y nuevos.

Escalado
Sea claro en lo que significa escala.

 Expansión de la base de clientes
 Crecimiento de ingresos
 Expansión de un proyecto o equipo para satisfacer la demanda
 Mantener o mejorar una proporción de personas a los sistemas o dinero gastado
 Crecer más rápido que los competidores
 Expandir ubicaciones
Considerar la externalización de algunos trabajos para ampliar.

Entonces puede ser fácilmente reducido.
Tanto la subcontratación completa o el uso de contratistas.

Escalado
Scale up
Scale down

Buenas maneras de resolver problemas de escalado
 Los proyectos Vampiro (que se alimentan de los recursos y la energía de otros proyectos) y los
zombies (tomar tiempo y recursos) pueden ser muy difíciles, porque hay individuos básicos cuya
sangre es esencialmente alimentar el proyecto.
 Es posible que ni siquiera se dan cuenta de cuánto de un drenaje del proyecto es en general para
la empresa.
 Cuando se acercan a la realidad del proyecto, pueden sentir que están siendo atacados
personalmente.
 Convencer a un individuo para abandonar el "precioso" proyecto al que ha dado tanto tiempo y
esfuerzo será un desafío, pero puede tener retornos inmensos.
 Las personas que se apasionan por los proyectos, ya tienen pasión: no hay que instalar pasión en
ellos, hay que redirigir esa pasión a algo que tiene valor para su compañía.

 Tan penetrante como el Internet es en estos días, cada pieza de software desarrollado debe ser
diseñada para estar disponible 24/7/365 o para tener contenido constantemente actualizando.
 Comprender y sopesar la importancia y complejidad de los proyectos y sus lanzamientos con el fin
de averiguar qué ciclo de lanzamiento tiene más sentido para cada uno.
 Diferentes proyectos en toda la organización podrían funcionar mejor con cadencias de liberación
diferentes.

Problema: Reducir la escala, pero algunos grandes proyectos están ocupando recursos y costos
 Reconocer proyectos que no agreguen valor a la organización reducida y cancelarlos
Problema: la escala produce descargas muy frecuentes y todo el software es imposible de mantener
con los niveles actuales de recursos
 Analizar qué software se requiere para estar disponible 24/7/365 o para tener constantemente la
actualización de contenido y que no lo es. Aplicar diferentes ciclos de liberación para cada uno
Problema: Gestión de conflictos

 No tolerar la cultura de la intimidación / culpa, sino reconocer y fomentar los conflictos saludables
como una forma de identificar nuevas ideas y soluciones a los problemas

Las políticas sociales y de contratación debe soportar escalado en DevOps
 Con el fin de hacer crecer una empresa pasado un cierto punto, usted tendrá que averiguar cómo
hacer que los equipos queden distribuidos de trabajo.
 Si no lo hace, disminuirá su capacidad para responder y reaccionar ante los cambios que afectan a
su organización, lo cual conducirá a la duplicación de esfuerzos y disminuir la satisfacción
individual y del equipo a medida que la gente se esfuerce por superar estas distancias de manera
efectiva.
 Estructuras organizacionales que bloquean a las personas en roles o que son impulsados por el
miedo puede conducir a un enfoque en la optimización de trabajo para mí, no para nosotros.
 La elección de procesos y herramientas que favorezcan a un individuo puede conducir a ganancias
a corto plazo que no son sostenibles para el equipo u organización a largo plazo.
 Más que contratar a personas que simplemente saben acerca de la automatización de la
infraestructura o la nube o los contenedores, las organizaciones y los equipos necesitan centrarse
en la evaluación de sus necesidades específicas y abordar los aspectos interpersonales y culturales
de contratación que son clave para crear y mantener una cultura DevOps.

Las políticas sociales y de contratación debe soportar escalado en DevOps
 Mirar el tamaño del equipo - los equipos pequeños de 5 - 7 funcionan bien

 Los equipos más grandes se vuelven burocráticos y pueden sofocar la innovación
 Promover desde dentro así como contratar desde fuera
 Mantener el conocimiento y la motivación, pero también aportar nuevas ideas y habilidades
necesarias
 Abordar los aspectos interpersonales y culturales, así como las necesidades técnicas al contratar
 Invertir en capacitación y apoyo al personal subalterno o nuevos empleados
 Mire los factores de motivación - beneficios, oportunidades y carga de trabajo, así como salarios
competitivos

Módulo 5
Fin de la Vida Útil
Agenda del Curso



 Condiciones de Fin de la Vida Útil para un producto o servicio
Módulo 5 Fin de la Vida Util 317

Módulo 5
Fin de la Vida Útil
Condiciones de Fin de la Vida Útil para un producto o servicio
En la sección de Condiciones de Fin de la Vida Útil para un producto o servicio el alumno será capaz
de:
 explicar qué condiciones se deben satisfacer antes de terminar un producto o servicio.

Condiciones a satisfacer antes de terminar un producto o servicio
El fin de la vida útil es tratado como una historia como otras condiciones
 La historia dirá por qué, por ejemplo, no más necesidad del negocio, reemplazo por un servicio
más barato / más simple / más eficaz
 La historia indicará cuáles son las condiciones, por ejemplo,
 Qué sucede con cualquier información / documentación / herramientas / otros componentes
 Cómo asegurarse de que cualquier servicio de reemplazo esté listo antes de cerrar el viejo
 Cuándo cerrar y en qué secuencia

Condiciones a satisfacer antes de terminar un producto o servicio

1 FIN DE VIDA

Módulo 6
Actividades Prácticas
Agenda del Curso


El cumplimiento de asignaciones prácticas es parte de los requisitos de certificación del EXIN DevOps
Master.
Cada Actividad se encuentra compuesta de cuatro sub actividades que miden distintas capacidades y
habilidades
Módulo 6 Actividades Prácticas 325

Forma de Trabajo
1. el alumno planea las actividades dentro de la asignación, a menos que se indique lo contrario.
2. el alumno se comunica y trabaja con otros cuando sea necesario.
3. Los candidatos ofrecen sus propias soluciones.
4. el alumno contribuye a la calidad de la asignación, especialmente en el trabajo grupal.
5. Las soluciones proporcionadas son realistas y, por tanto, aptas para el escenario o estudio de
caso.
6. Las soluciones proporcionadas coinciden con los objetivos de negocio y TI.

Módulo 6
Actividad 1
Objetivos de la Actividad
el alumno debe:
 Demostrar liderazgo para la construcción e implementación de soluciones de Sistemas de
Información innovadoras a largo plazo.
 Asegurar el contenido del SLA.
 Analizar sistemáticamente los datos de desempeño y comunicar los hallazgos a los expertos de alto
nivel. Escalar posibles fallos en el nivel de servicio y riesgos de seguridad, recomendando acciones
para mejorar la fiabilidad del servicio. Controlar los datos de confiabilidad contra SLA
 Establecer relaciones confiables con los clientes (internos) y ayudarlos a aclarar sus necesidades.

Escenario 1
Tema:
Alineación de la Estrategia de TI y la Estrategia de Negocios
Objetivo:
el alumno debe demostrar que sabe cómo
 Analizar desarrollos futuros en la aplicación de procesos y tecnologías empresariales
 Determinar los requisitos para los procesos relacionados con los servicios TIC
 Identificar y analizar las necesidades de los usuarios / clientes a largo plazo

Escenario 2
Tema:
Gestión de Niveles de Servicio
Objetivo:
 Hacer SLAs y UCs aplicables
 Negociar objetivos de nivel de servicio
 Tener en cuenta las necesidades y la capacidad de las partes interesadas y las empresas

Escenario 3
Tema:
Entrega de Servicios
Objetivo:
 Identificar fallas en la entrega de servicios
 Interpretar los requisitos de prestación de servicios TIC
 Registrar incidentes de servicio
 Mantener herramientas de monitoreo y manejo
 Recomendar acciones para mejorar la fiabilidad del servicio

Escenario 4
Tema:
Identificar Necesidades
Objetivo:
 Analizar las necesidades del cliente
 Aclarar las necesidades del cliente
 Participar en la implementación o proceso de configuración
 Ofrecer soluciones para las necesidades del negocio

Módulo 6
Actividad 2
el alumno debe:

Escenario 1
Tema:
Alineación de la Estrategia de TI y la Estrategia de Negocios
Objetivo:

Escenario 2
Tema:
Objetivo:

Escenario 3
Tema:
Objetivo:

Escenario 4
Tema:
Objetivo:

Módulo 6
Actividad 3
el alumno debe:

Escenario 1
Tema:
Alineación de l1 Estrategia de TI y la Estrategia de Negocios
Objetivo:

Escenario 2
Tema:
Objetivo:

Escenario 3
Tema:
Objetivo:

Escenario 4
Tema:
Objetivo:

Módulo 7
Preparación del Examen
Agenda del Curso


En este módulo el alumno rendirá un examen reducido de práctica y apoyado por el instructor en la
revisión de los resultados.
Módulo 7 Preparación del Examen 347

Módulo 7
Preparación del Examen
Examen de Práctica
Cierre y Despedida
El término DevOps es una contracción de las palabras inglesas "Development" (Desarrollo) y

"Operations" (Operaciones). DevOps es un conjunto de prácticas recomendadas que enfatizan la
colaboración y la comunicación entre los profesionales de TI (desarrolladores, administradores,
operadores, personal de asistencia técnica) en el ciclo de vida de las aplicaciones y los servicios, lo
que conduce a:
 Integración Continua: transferencia sencilla desde Desarrollo hasta Operaciones y Soporte
 Despliegue Continuo: publicación de versiones de forma continua o con la máxima frecuencia
posible
 Retroalimentación Continua: búsqueda de retroalimentación de las partes interesadas durante
todas las etapas del ciclo de vida
DevOps cambia la forma en la que las personas piensan sobre su trabajo; DevOps valora la diversidad
del trabajo realizado, respalda los procesos intencionados que aumentan la velocidad a la que las
empresas crean valor y mide el efecto del cambio técnico y social. DevOps es una manera de pensar y
una manera de trabajar que permite a las personas y a las empresas desarrollar y mantener
procedimientos de trabajo sostenibles.

Un DevOps satisfactorio consiste en:

 Promover una cultura libre de culpa en la que se compartan historias y se desarrolle la empatía
para conseguir que las personas y los equipos desempeñen sus funciones de forma eficaz y
duradera.
 Proporcionar aplicaciones y servicios al Negocio según el modelo Just-in-Time (JiT).
 Garantizar la continuidad de los servicios de TI mediante una aproximación a las necesidades de
negocio basada en el riesgo.
 Gestionar el ciclo de vida completo de las aplicaciones y los servicios, incluidas las condiciones de
fin de la vida útil.

Esta Certificación
Esta certificación pretende aportar competencias prácticas al conocimiento con el fin de que una
persona con la certificación DevOps Master pueda implementar el modelo DevOps de forma
satisfactoria en un equipo y promover sus principios en la empresa.
Esta certificación ha sido desarrollada en colaboración con expertos en el sector DevOps

Contexto de DevOps

Agenda del Curso DevOps Master


Contenido cubierto en el curso
 El curso cubre el contenido detallado por la guía oficial vigente

 El curso cubre competencias sobre:
Adopción de DevOps
Planificación, Requerimientos y Diseño
Desarrollo y Despliegue
Operación y Escalado
Fin de la Vida Útil
 El curso además contempla el desarrollo de actividades prácticas en las que se deben aplicar los
conocimientos adquiridos


Certificacion DevOps Master PDF

Cargado por

Copyright:

Formatos disponibles

Certificacion DevOps Master PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Certificacion DevOps Master PDF

Cargado por

Copyright:

Formatos disponibles

Certificación DevOps Master

 Registro, Asistencia y Evaluación

 Intentar al máximo sentirse libres

Documentos electrónicos conteniendo:

Algunos documentos se entregan clase a clase

Basado en la Guía de Preparación EXIN DevOps Master Edición 201703

El término DevOps es una contracción de las palabras inglesas "Development" (Desarrollo) y

Objetivos y Agenda del Curso 12

Un DevOps satisfactorio consiste en:

Objetivos y Agenda del Curso 13

Esta certificación ha sido desarrollada en colaboración con expertos en el sector DevOps

Objetivos y Agenda del Curso 14

Objetivos y Agenda del Curso 15

Módulo 1: Adopción de DevOps

Objetivos y Agenda del Curso 16

 El curso cubre el contenido detallado por la guía oficial vigente

Objetivos y Agenda del Curso 17

A Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

C Success to Enterprise DevOps

Objetivos y Agenda del Curso 18

D The Phoenix Project

Objetivos y Agenda del Curso 19

1 CONOCIMIENTOS PREVIOS NECESARIOS

Objetivos y Agenda del Curso 20

Módulo 1: Adopción de DevOps

Objetivos y Agenda del Curso 22

En este módulo el alumno reconocerá los elementos centrales de:

Módulo 1 Adopción de DevOps 23

En la sección de Mentalidad y Beneficios de DevOps el alumno será capaz de:

Módulo 1 Adopción de DevOps 25

Los principales elementos de DevOps son:

Módulo 1 Adopción de DevOps 26

Módulo 1 Adopción de DevOps 27

 La palabra DevOps es una contracción de 'Desarrollo' y 'Operaciones'

Módulo 1 Adopción de DevOps 28

Ejemplo de anti patrón: Implementación manual de software

Módulo 1 Adopción de DevOps 29

Pre-Devops Development Pre-Devops Operations

Lento, manual, multi-equipos no trabajando juntos, Rápido, automatizado, equipo

Módulo 1 Adopción de DevOps 30

Módulo 1 Adopción de DevOps 31

Módulo 1 Adopción de DevOps 32

Módulo 1 Adopción de DevOps 33

Módulo 1 Adopción de DevOps 34

Módulo 1 Adopción de DevOps 35

Módulo 1 Adopción de DevOps 36

 El software no existe por separado de los usuarios y desarrolladores

Módulo 1 Adopción de DevOps 37

Módulo 1 Adopción de DevOps 38

 El entorno tradicional ve "el error humano como la causa de los problemas".

Módulo 1 Adopción de DevOps 39

Visión Antigua Visión Nueva(Devops)

Módulo 1 Adopción de DevOps 40

Módulo 1 Adopción de DevOps 41

Módulo 1 Adopción de DevOps 43

En la sección de Cultura Organizativa el alumno será capaz de:

Módulo 1 Adopción de DevOps 45

Colaboración Afinidad Herramienta Escalado

Módulo 1 Adopción de DevOps 46