1
00:00:00,460 --> 00:00:13,090
Bienvenidos a ITIL 4 sin filtros, elevando
en la en presentado por Con Punto y Koma.

2
00:00:13,240 --> 00:00:14,180
Yo soy Julián

3
00:00:14,250 --> 00:00:26,700
y yo soy Alex, y hoy vamos a sumergirnos
en una confusión clásica del mundo de
la gestión de servicios de TI Release
management y Deployment management.

4
00:00:27,384 --> 00:00:31,075
La gente los confunde todo el tiempo.

5
00:00:31,195 --> 00:00:32,214
Así es.

6
00:00:32,214 --> 00:00:34,375
Y lo entendemos, es fácil confundirse.

7
00:00:34,464 --> 00:00:45,474
Pero hoy vamos a desmenuzando todo, no
solo que son sino como trabajan juntos
y como se conectan con Change Enablement
los value streams y bueno, todo lo demás.

8
00:00:45,504 --> 00:00:46,465
Sí, sí.

9
00:00:46,795 --> 00:00:55,934
Así que si alguna vez pensaste no
son lo mismo, quédate con nosotros
porque, bueno, Al final del episodio,

10
00:00:56,114 --> 00:01:03,525
te va a quedar clarísimo que son muy
distintos, pero también inseparables.

11
00:01:04,485 --> 00:01:07,395
Bueno, vamos a aclararlo de entrada.

12
00:01:07,399 --> 00:01:12,229
Release management es básicamente hacer
que algo nuevo o cambiado esté disponible.

13
00:01:12,350 --> 00:01:15,559
Es como decir hey usuarios, aquí
está lo nuevo que prometimos.

14
00:01:16,279 --> 00:01:19,820
Es el momento en que los
cambios se vuelven reales.

15
00:01:20,149 --> 00:01:34,670
O sea realmente utilizables, puede ser una
aplicación nueva, una función genial o no
sé un parche de seguridad importante, pero
todo gira en torno a hacerlo disponible.

16
00:01:34,789 --> 00:01:35,720
Exacto.

17
00:01:35,974 --> 00:01:39,034
Deployment management
es más tras bambalinas.

18
00:01:39,214 --> 00:01:45,094
Se trata de mover los componentes
software, hardware, datos a los
entornos donde deben ejecutarse.

19
00:01:45,184 --> 00:01:48,034
Puede ser staging, test,
producción, lo que sea.

20
00:01:48,094 --> 00:01:55,204
Y aquí es donde la gente se confunde
algo puede estar desplegado o
deployed, pero no liberado o released.

21
00:01:55,294 --> 00:01:59,704
En otras palabras, el código puede
estar en producción, pero como.

22
00:02:00,539 --> 00:02:02,309
En modo fantasma.

23
00:02:03,059 --> 00:02:08,430
Sí, como si estuviera en modo
sigiloso hasta que Release
management no da la luz verde.

24
00:02:08,489 --> 00:02:09,840
Los usuarios ni se enteran

25
00:02:09,989 --> 00:02:10,590
hasta ahora.

26
00:02:10,739 --> 00:02:15,989
Hablamos de Release y Deployment como
piezas separadas del rompecabezas, no?

27
00:02:16,049 --> 00:02:16,440
Sí.

28
00:02:16,530 --> 00:02:23,430
Y eso está bien para explicarlos, pero
en la práctica, especialmente en entornos
modernos, están súper entrelazados.

29
00:02:23,579 --> 00:02:24,540
Exactamente.

30
00:02:24,780 --> 00:02:27,930
Y ahí es donde entra lo interesante.

31
00:02:28,185 --> 00:02:36,045
Porque cada vez más organizaciones
usan Agile y DevOps para, ya sabes,
acelerar la entrega de valor.

32
00:02:36,255 --> 00:02:43,785
Y cuando vas rápido pero rápido de verdad,
Release y Deployment, no solo tienen
que colaborar, tienen que fluir juntos.

33
00:02:43,965 --> 00:02:46,185
Ahí es donde entra si CI/CD.

34
00:02:46,340 --> 00:02:46,640
Si.

35
00:02:46,640 --> 00:02:56,480
CI/CD, que significa en español,
integración continua y entrega y
despliegue continuo, es como la columna

36
00:02:56,480 --> 00:03:01,820
vertebral de los pipelines modernos
y honestamente cambia por completo.

37
00:03:01,880 --> 00:03:04,830
Cómo se comportan Release y Deployment

38
00:03:04,920 --> 00:03:05,760
Total.

39
00:03:05,790 --> 00:03:13,139
En una cultura DevOps no esperas al
próximo mes, estás empujando cambios
todo el tiempo, y eso hace que Release

40
00:03:13,139 --> 00:03:18,420
y Deployment sean más fluidos, más
automáticos y también más riesgosos
si no tienes un enfoque estructurado,

41
00:03:18,599 --> 00:03:20,550
pero también más poderosos.

42
00:03:21,180 --> 00:03:28,680
Así que vamos a desglosar CI/CD, porque
es el motor detrás de cómo evolucionan
estas prácticas en tiempo real.

43
00:03:29,224 --> 00:03:36,334
CI es integración continua, o sea,
los desarrolladores suben código al
repositorio todo el tiempo y se compila

44
00:03:36,334 --> 00:03:40,295
y prueba automáticamente así evitas
desastres cuando se unen más tarde

45
00:03:40,445 --> 00:03:42,545
y CD tiene dos significados.

46
00:03:43,115 --> 00:03:47,524
Entrega continua significa que el
software está siempre listo para liberar.

47
00:03:48,005 --> 00:03:50,344
Pero alguien decide cuándo a hacerlo.

48
00:03:50,644 --> 00:03:51,695
Eso es otro nivel.

49
00:03:51,934 --> 00:03:56,075
El despliegue continuo, todo lo que pasa,
las pruebas se despliega automáticamente.

50
00:03:56,224 --> 00:03:56,554
Pum.

51
00:03:56,584 --> 00:03:58,594
Producción sin la intervención humana.

52
00:03:58,774 --> 00:04:04,024
Pero ojo, eso solo funciona si Release
y Deployment están súper coordinados.

53
00:04:04,294 --> 00:04:05,644
Muy bien sincronizados.

54
00:04:06,315 --> 00:04:07,394
Se despliega.

55
00:04:07,425 --> 00:04:10,815
Pero igual hay que decidir
cuándo, cómo y para quién.

56
00:04:11,055 --> 00:04:18,125
Sí, como cuando lanzas una funcionalidad,
pero solo la activas para un pequeño
grupo de usuarios, digamos a un 5%,

57
00:04:18,125 --> 00:04:23,056
para probar que todo funcione bien
antes de habilitarla para todos,
eso se llama un "canary release".

58
00:04:23,289 --> 00:04:26,890
Bueno antes de seguir, vale
la pena repasar algo clave.

59
00:04:27,159 --> 00:04:30,400
La cadena de valor del
servicio, o service value chain.

60
00:04:30,669 --> 00:04:33,810
Son seis actividades centrales en ITIL 4.

61
00:04:34,120 --> 00:04:34,570
Correcto.

62
00:04:34,690 --> 00:04:40,870
Planificar, mejorar, involucrar,
diseño y transición, obtener y
construir, y entrega y soporte.

63
00:04:41,169 --> 00:04:44,010
Y Release management
aparece en casi todas.

64
00:04:44,310 --> 00:04:47,910
Diseño, transición, entrega, mejora.

65
00:04:47,910 --> 00:04:48,990
Incluso planificación

66
00:04:49,310 --> 00:04:53,150
Deployment management también,
principalmente en diseño,
transición y construcción.

67
00:04:53,300 --> 00:04:54,560
Es el que mueve las piezas.

68
00:04:54,830 --> 00:04:58,580
Pero nada de esto funciona
sin Change enablement, y ojo.

69
00:04:58,909 --> 00:05:01,820
No es solo para decir si o no a un cambio

70
00:05:01,909 --> 00:05:02,330
Claro.

71
00:05:02,390 --> 00:05:04,700
Es como el pegamento estratégico.

72
00:05:05,060 --> 00:05:10,310
Asegura que cada cambio esté
alineado con el riesgo, el tiempo, la
prioridad y los objetivos de negocio.

73
00:05:10,600 --> 00:05:15,190
Define el tipo de cambio, quien participa,
cuáles son los criterios de éxito.

74
00:05:15,370 --> 00:05:22,443
Todo eso se evalúa antes de aprobar,
pero sigue vigilante durante todo
el proceso de Release y Deployment

75
00:05:22,623 --> 00:05:26,734
para garantizar que Release
y Deployment ejecuten lo que
se pensó, que no se desvíe.

76
00:05:26,854 --> 00:05:35,914
Es como una producción de teatro: Change
enablement es el productor, Deployment,
el equipo técnico y Release, el
director que dice "luz, cámara, acción".

77
00:05:36,364 --> 00:05:37,654
Ilustremos un ejemplo.

78
00:05:37,929 --> 00:05:41,589
Supongamos que lanzamos un nuevo
chat bot para atención al cliente.

79
00:05:41,949 --> 00:05:46,808
Veamos... el equipo de desarrollo
lo construye, Change enablement
da el visto bueno y Deployment

80
00:05:46,808 --> 00:05:50,589
lo lleva a staging y luego a
producción, pero no está activo aún

81
00:05:50,899 --> 00:05:52,659
Ahí entra Release management.

82
00:05:52,828 --> 00:05:56,578
Se preparan los manuales, se
entrena al equipo de soporte

83
00:05:56,619 --> 00:05:59,109
actualiza la base de
datos de conocimiento.

84
00:05:59,229 --> 00:06:01,839
Se libera la funcionalidad
para un grupo pequeño.

85
00:06:01,994 --> 00:06:04,724
Se monitorea el rendimiento,
se identifican errores.

86
00:06:04,933 --> 00:06:08,474
Y si todo está bien, se amplía
a toda la base de usuarios.

87
00:06:08,744 --> 00:06:12,313
Y si algo falla, todo se reversa.

88
00:06:12,643 --> 00:06:19,273
Es por eso que Release and
Deployment deben tener planes para
regresar todo a su estado anterior.

89
00:06:19,664 --> 00:06:25,273
Eso es ITSM en acción resiliente
responsivo y flexible.

90
00:06:25,618 --> 00:06:29,398
Julián y cómo sabremos qué
tal lo estamos haciendo

91
00:06:29,698 --> 00:06:30,328
Midiendo.

92
00:06:30,898 --> 00:06:39,479
En Release management, debemos medir
la satisfacción de usuarios, número de
Releases exitosos, incidentes derivados
de cambios, cumplimiento de cronogramas

93
00:06:39,748 --> 00:06:47,369
y en Deployment management, porcentaje
de despliegues exitosos, errores de
implementación, tiempos de respuesta.

94
00:06:47,399 --> 00:06:49,799
Cumplimiento de ventanas de mantenimiento

95
00:06:50,199 --> 00:06:57,599
y con la automatización, las
herramientas como pipelines de CI/CD,
integración con pruebas automatizadas
y verificación de entornos.

96
00:06:57,809 --> 00:07:00,959
Hacen todo más rápido también más seguro.

97
00:07:01,449 --> 00:07:06,919
Claro, siempre que haya roles definidos
y modelos de gobernanza que lo respalden.

98
00:07:07,789 --> 00:07:14,399
- Julián ITIL 4 se basa en un
enfoque holístico y eso se
refleja en sus cuatro dimensiones.

99
00:07:14,949 --> 00:07:23,019
Organización y personas, información
y tecnología, socios y proveedores
y flujos de valor y procesos

100
00:07:23,229 --> 00:07:25,119
A ver... en Release y Deployment.

101
00:07:25,419 --> 00:07:26,199
Esto es clave.

102
00:07:26,499 --> 00:07:33,219
Necesitas personas capacitadas,
tecnología adecuada, coordinación con
terceros y procesos bien diseñados.

103
00:07:33,778 --> 00:07:40,318
Por ejemplo, si el proveedor de una
herramienta no libera una versión
compatible a tiempo, eso afecta tu

104
00:07:40,318 --> 00:07:45,688
release o si tu equipo no está alineado
con el proceso, el cambio puede fallar.

105
00:07:45,929 --> 00:07:47,878
Cada dimensión influye en la otra.

106
00:07:48,028 --> 00:07:53,638
Y cuando las cuatro están
equilibradas, la entrega de valor
es sostenible, confiable y ágil

107
00:07:54,028 --> 00:08:00,958
Para cerrar un mensaje claro,
Release y Deployment no son
actividades técnicas aisladas.

108
00:08:01,213 --> 00:08:03,344
Son prácticas estratégicas

109
00:08:03,704 --> 00:08:04,664
Totalmente.

110
00:08:04,844 --> 00:08:12,284
Y cuando están bien integradas con
Change enablement, y con la cadena
de valor, la organización puede
entregar cambios con confianza

111
00:08:12,584 --> 00:08:18,193
y eso se traduce en usuarios
satisfechos, menos incidentes y más valor

112
00:08:19,114 --> 00:08:22,354
y también noches tranquilas
para los equipos de operaciones.

113
00:08:22,994 --> 00:08:29,474
Gracias por acompañarnos en este
episodio de ITIL 4 Sin Filtros
presentado por Con Punto y Koma.

114
00:08:29,944 --> 00:08:32,504
Si te gustó compártelo y suscríbete.

115
00:08:32,864 --> 00:08:37,724
Y cuéntanos tus experiencias, liberando
cambios, las buenas y las que no tanto

116
00:08:38,324 --> 00:08:40,364
Te esperamos en el próximo episodio.

117
00:08:40,598 --> 00:08:41,468
Hasta entonces...

118
00:08:41,708 --> 00:08:44,319
...sigue entregando valor con propósito.