Y ahora tenemos al bueno de Pablo, que está aquí esperando.
Hola, Pablo, ¿cómo estás?
Hola, ¿cómo andas? ¿Todo bien? ¿Se escucha bien?
Muy bien. Sí, se te escucha perfectamente.
Pues, lo siento por la...
No hay problema.
...retraso. Y nada, vamos contigo,
porque vienes a hablarnos de Continuous Integration
en Continuous Deployment,
que es un tema bastante interesante, que le puede interesar
a toda la gente del mundo de la programación,
no solo Frontend, sino a todo el mundo.
Y nada, te dejo
en los mandos para que nos cuentes
sobre esto. ¿Vale, Pablo?
Gracias, gracias. Ahí...
Bueno, listo, me activas vos la pantalla directamente, ¿no?
Sí, yo le doy. Mira, ¿ves?
Excelente, gracias. Gracias, Mido.
Vale, ahí de un abrazo. Cuídate y
mucha suerte. Dale, dale.
Prometo no pasarme de tiempo. Vamos a ver.
Vamos a hablar un poquito
entonces de qué es lo que se dice de...
Para aquellos que no
saben, o tal vez el público
que sigue a Mido generalmente,
como dijo recién, era más
Frontend, más developers, entonces
mucho no se ve en el mundo
de los desarrolladores,
qué es lo que es CICD,
vamos a hablar un poquito de eso.
Y todos conocen estas empresas
con métodos tradicionales,
donde el equipo de desarrollo
es el equipo que desarrolla,
¿sí?
Y se le dice el equipo de dev
y también tenemos el equipo de ops
o el equipo de operaciones,
que es generalmente el equipo
de infraestructura, ¿no?
El que hace prácticamente todo lo demás.
El que se encarga de poner
el código en producción,
el que se encarga de los servidores,
de instalarlos, de configurarlos.
Y generalmente
hay como un problema
entre estos dos equipos.
Es muy normal ver fricción
entre estos dos equipos,
ya que como el equipo de operaciones
lo que quiere es la estabilidad,
quiere que esté todo funcionando,
quiere que no se caiga el servidor,
y el equipo de desarrollo
lo que quiere hacer es lo contrario,
digamos, es poner cosas en producción,
moverse rápido,
causar disrupciones en el buen sentido,
o sea, hacer cambios.
Siempre hay esta fricción, ¿no?
Uno quiere estabilidad
y el otro quiere movilidad,
el otro quiere velocidad.
Entonces, son cosas que no concuerdan entre sí,
siempre se van a llevar mal.
La idea de DevOps
es tratar de cambiar esto
y hacer que estos equipos
trabajen en conjunto.
Las empresas modernas
se ve mucho más
esta cultura
de la cultura de DevOps,
que es lo que vamos a estar hablando hoy,
que es necesario explicarlo
para que ustedes entiendan
lo que es CICD.
Bueno, ¿cuál es la idea
de la cultura de DevOps?
La idea de la cultura de DevOps
es brindarle a los desarrolladores
el poder
y las responsabilidades
para moverse más rápido.
¿Qué quiere decir eso?
Que no solamente
le vamos a dar
la posibilidad
de poner código en producción
a las 3 de la mañana,
un domingo a las 3 de la mañana.
Si lo quieren poner en producción,
no hay ningún problema.
Te vamos a dar todas las herramientas
para que el equipo de desarrollo
lo pueda hacer,
pero también hay que tener cuidado
porque ya que estoy dando
este poder,
también vas a tener
esa responsabilidad.
¿Qué quiere decir?
Que en lugar de que
la alerta
le llegue al equipo
de infraestructura,
seguramente va a llegar
esta alerta
al equipo de desarrollo,
ya que vas a tener
todas las herramientas
para no solamente
poner el código en producción,
sino volver atrás
ese código en producción
o tal vez
de vaguear problemas
en estos servidores,
¿no?
Entonces,
es muy común
que en la cultura de DevOps
no solamente
le damos el poder
a los desarrolladores,
sino que también
le damos la responsabilidad
a los desarrolladores.
Bueno,
pero ¿cómo se aplica
esta cultura de DevOps?
Pablo,
a ver,
seguramente
ustedes están preguntando,
bueno,
pero ¿cómo hago
para aplicar esto
en mi empresa?
Bueno,
esto es un trabajo
en equipo
de toda ingeniería,
no solamente
el equipo de infraestructura,
no solamente
el equipo SRE,
es el equipo
que tiene que,
la responsabilidad
de aplicar
a esta cultura
en la empresa,
es un trabajo
en conjunto
con todo
el equipo de ingeniería.
Generalmente
el equipo SRE
es el que crea
estas herramientas,
el que
lleva estas herramientas
a los desarrolladores
para que puedan usarlas
y puedan poner ese código
en producción
y por eso digo
que es el equipo SRE,
muchas veces
se le dice
el equipo de infraestructura
también
o el equipo de operaciones,
pero esto
ha cambiado un poco
en el último tiempo
y ahora además
se le dice
equipo SRE
o Site Reliability Engineer
que no solamente
se encargan
de configurar,
mantener esos servidores,
mantenerlos andando,
sino darles
estas herramientas.
Entonces,
estos SRE
no solamente
mantienen los servidores,
sino que pueden llegar
a desarrollar
y ahí seguramente
ya se están imaginando
cómo es la cosa acá.
No solamente
el equipo de SRE
va a desarrollar,
sino que seguramente
se va a apoyar
en el equipo de desarrollo
para aplicar
estas buenas prácticas
de desarrollo
también en todas
las herramientas
que necesitamos
en el equipo de SRE.
Entonces,
es muy común
ver desarrolladores
trabajando en conjunto
en el equipo de SRE
o mejor dicho,
incluso ver desarrolladores
en el equipo de SRE.
Muchas veces
yo estoy trabajando
en un equipo de SRE
y si quiero
entrevistar
para un nuevo integrante,
es muy probable
que busque un desarrollador,
es muy probable
que busque alguien
que me ayude
a crear estas herramientas
para el equipo de SRE.
Así que esto
se ve
en estas empresas
donde trabajan
mucho más en conjuntos.
La idea es dejar
de ser el gatekeeper,
o sea,
dejar que el equipo
de SRE,
dejar que ellos
se encarguen
de bloquear
o decidir
si el código
va a producción o no.
La idea es que
el equipo de SRE
te da estas herramientas
para que el equipo
de desarrollo
lo pueda poner
en producción.
Darle más poder
a toda ingeniería.
¿Cómo hacemos esto?
Bueno,
ahí llegamos
al título
de esta charla.
Esto haciendo
es deploys
automáticos
y seguros.
¿Se acuerdan
recién
que yo les decía
que el equipo
de desarrollo
quería moverse rápido
y el equipo
de SRE
o el equipo
de operaciones
quiere moverse lento
porque quiere
que sea todo seguro?
Bueno,
la idea de CICD
es que
tratemos de poner
estas dos cosas juntas,
o sea,
que sean automáticos
para que sean rápidos,
pero a la vez
que sean seguros.
O sea,
que si ellos
cometen un error
de alguna forma,
por ejemplo,
poder volver atrás
del cambio,
sí se puede,
sí es algo automático.
Bueno,
¿por qué?
¿Por qué queremos
aplicar la cultura
de OPS?
Bueno,
porque la realidad
es que el 70%
de los incidentes
son causados
por cambios
en el código.
¿Se acuerdan
seguramente
hace un tiempo
el problema este
que se vio
en todos lados
de CrowdStrike?
Este software
que causó
millones y millones
de máquinas
alrededor del mundo,
no solamente
máquinas de clientes
sino servidores
que dejaran
de funcionar
y eso causó
que se cayeran
muchos negocios,
que no anduvieran
los aeropuertos,
que no anduvieran
los bancos.
Entonces,
y todo esto
fue causado
por un error
de código.
O sea,
una persona
puso un error humano,
puso algo
en producción
que no tenía
que estar.
Así que
al nosotros
aplicar
estos 6D
de automatización
y de seguridad,
tratamos de evitar
este problema.
¿Cómo evitamos
este problema?
Bueno,
hacemos deploys
progresivos.
Esto es algo
normal.
La idea sería
no poner
mucho código
junto,
o sea,
no juntar código
durante un mes
y ponerlo
en producción,
sino hacerlo
de a poco,
¿sí?
Entonces,
por ejemplo,
hoy voy a trabajar
en una feature
donde voy a hacer
algún cambio.
Posiblemente
trabajo hoy
durante ese día,
tal vez uno o dos días
como mucho,
y ya nomás lo pongo
en producción.
Hay muchas herramientas
que nos ayudan
a poner ese código
en producción,
pero sin que quede
en modo usable,
digamos.
Entonces,
de esta forma
nos aseguramos
que después
si alguien
mete un cambio
muy grande,
no tenga que esperar
a que yo ponga
ese código
también para que sea
compatible.
Al nosotros
hacer
deploys
progresivos,
nos aseguramos
de que esos cambios
sean cada vez más chiquitos
y sean más fáciles
de debaguear.
Porque de esta forma,
al tener códigos
chiquitos,
cambios chiquitos,
podemos detectarlos
rápidamente
y temprano,
o sea,
antes de que pasen
o por lo menos
lo más rápido posible.
Y aparte,
si nosotros
ponemos
poco código
en producción
o poco código
en los nuevos servidores,
si pasa algún problema,
ya sabemos
que es ese pedacito
nada más
del código
que tenemos
que volver atrás.
En cambio,
si nosotros ponemos
un mes de trabajo
en producción de una,
volver atrás
un mes de trabajo
obviamente a nadie
le va a gustar.
Entonces,
es mejor
poner de a poquito
cosa que volvemos
atrás solamente
ese pedacito.
De esta forma
podemos hacer
rollbacks,
o sea,
volver atrás del código
de forma rápida,
de forma segura.
Y una de las cosas
que más
siempre recomiendo
es el uso
de feature flags.
Tengo un pequeño
bias con esto
porque yo trabajo
por una empresa
de feature flags,
pero es muy importante
que tengamos
este concepto
de feature flag
que seguramente
Mido ha hablado
de esto
en sus streams
o seguramente
ahora te pongo
la tarea Mido
de que hagas
un video sobre esto,
donde nosotros
podemos habilitar
o deshabilitar código
de forma centralizada,
o sea,
sin hacer un deploy.
A ver,
¿por qué queremos
automatización?
Porque nosotros
podemos hacer
cosas consistentes
y repetibles,
o sea,
nosotros hacemos
un cambio
y siempre lo podemos
hacer de ahora
en adelante
y lo podemos
hacer muchas veces.
Obviamente ahorramos
tiempo a largo plazo,
esto yo lo entiendo
y es algo que
muchas veces
la gente no quiere
automatizar algo
porque piensa,
no, bueno,
pero esto lo hago
de vez en cuando,
tal vez no es tanto trabajo
y automatizarlo
me va a llevar
mucho más tiempo
que el tiempo que gano
o que el tiempo
que me ahorro
cuando hago algo a mano.
Esto es verdad
y muchas veces
hay que tener en cuenta,
no hay que ser tan loco
e ir y automatizar todo,
pero la realidad
es que a largo plazo
siempre vas a recuperar
ese tiempo
y aparte
evitas estos problemas.
Al vos automatizar
te aseguras
de que sea consistente,
que sea repetible,
¿sí?
entonces sacás una variable
que sería
el del error humano,
por lo menos
lo reducís bastante.
Obviamente
te permite escalar,
al automatizar
es mucho más fácil escalar,
en cambio
si vos empezás
a hacer cosas manuales,
esto nos pasó,
por ejemplo,
en una empresa
donde yo trabajaba,
teníamos una persona
que estaba dedicada
a hacer los deploys
de la empresa
y al principio
era fácil
porque éramos 30,
40 personas,
hacía uno,
dos deploys por día,
dentro de todo
no había tanto problema,
pero la empresa
empezó a crecer
y en un momento
llegábamos a mil ingenieros
y era imposible
hacer todos los deploys,
o sea,
estaba la persona
literalmente
las 8 horas
de su trabajo
haciendo deploys,
entonces no escalaba
hacerlo manual,
entonces no había
otra alternativa
que automatizar
todo esto.
Ok,
bueno,
gracias Pablo,
mucho gusto,
pero ¿qué es lo que es
CI, CD?
Bueno,
CI es Continuous Integration
y CD es Continuous Delivery
o Continuous Distribution,
vamos a ver la diferencia,
pero vamos a hacer
una pequeña pausa
y nos vamos,
me voy a presentar
porque no sé
si notaron
que no he dicho
nada de quién soy,
esta fue toda
solamente una intro
de lo que hemos hablado,
así que queda
una hora y media más
de charla más o menos,
no mentira mía,
te estoy diciendo un chiste,
quedan 10 minutos,
estamos re bien,
estamos re bien,
así que,
bueno,
mi nombre es Pablo Fredrickson,
soy principal SRB
en una empresa
que se llama Harness,
hace poco
yo trabajaba
por una empresa
que se llama Split,
fue adquirida por Harness,
tengo 18 años
de experiencia en IT,
soy amante
del software libre,
de las nuevas tecnologías,
veo el chat
de la risa de esto,
me gusta,
me gusta,
soy CNCF ambasador,
eso quiere decir
que ayudo
a la CNCF,
que la Cloud Native
Computing Foundation
que habla
de todos estos proyectos
que vamos a hablar
seguramente
o que yo hablo mucho
en mi canal
a promocionarlos
y también tengo
un canal de YouTube
que se llama Pelado Nerd
donde aquellos
que no me conocen
lo pueden buscar
y después al final
voy a poner el link
peladoner.com
para que chequen
todo eso,
así que bueno,
¿qué es lo que es
CI-CD?
Bueno,
como dije,
CI es Continuous Integration
y CD es Continuous Delivery
o Continuous Deployment.
Muchas veces CD
se puede encapsular
en estas dos cosas,
¿sí?
Y creo que este gráfico
es bastante fácil
de entender.
La parte de CI,
¿sí?
Es la parte del build,
la parte donde nosotros
construimos
nuestra aplicación.
En el caso de Java,
por ejemplo,
sería construir
un WAR,
en el caso de NPM,
construir,
no sé,
no sé nada,
perdón,
me doy,
no estaría que hubiera visto
un video todo,
pero la idea
es construir
ese binario,
o el Go,
construir un binario
o tal vez una imagen
de Docker,
¿sí?
Todo esto lo hacemos
en la parte
de Continuous Integration.
También podemos hacer
NPM RAM build.
Bueno,
gracias Diego,
buenísimo.
No sé,
no sé qué significa eso.
Vamos entonces,
también vamos a testear,
¿sí?
Vamos a probar,
por ejemplo,
podemos tener
Unit Testing
y esas cosas
para asegurarnos
de que nuestra imagen
esté bien hecha,
nuestro código
sea potable,
tenga buena salud
y esto se termina,
la parte del Continuous Integration
termina en el merge,
¿sí?
Una vez que hacemos el merge,
o sea,
que ponemos nuestro código
en la branch principal,
main o master,
termina el Continuous Integration
y empieza lo que se llama
el Continuous Delivery.
Entonces,
el Continuous Delivery,
por ejemplo,
sería automáticamente
agarrar esa imagen
y subirla a un repositorio,
¿sí?
Para que la pueda
alguien más descargar.
Y en el caso
de que nosotros
también tengamos
Deploys,
porque no siempre
deployamos
nuestro código de producción,
muchas veces
nuestro Deploy
es simplemente
ponerlo en un repositorio.
Si nosotros somos,
por ejemplo,
una empresa
que hace el código
de,
no sé,
de algo de NPM,
NPM,
Run,
Build,
no sé qué,
terminaría
ese código
cuando se sube
al repositorio
y está disponible
para que otra persona
lo pueda descargar.
Pero no haces un Deploy.
En el caso
de que tengamos
una empresa con servicios
donde nosotros
hacemos código
y lo ponemos en producción,
o sea,
hacemos que este sea
el que funcione
en nuestra página,
ahí sí haríamos
el siguiente paso
que sería
Continuous Deployment,
que es automáticamente
hacer un Deploy
a producción.
Y acá cuando digo
automáticamente
hay que agarrarlos
con pinzas
porque no siempre
es automático,
la realidad es que
hay veces que
la automatización
solamente funciona
hasta un entorno
de stage,
un entorno de pruebas,
¿sí?
Y tal vez
para ir a producción
se requiere un paso manual,
pero este paso manual
está relativamente
automatizado,
o sea,
simplemente,
por ejemplo,
tocar un botón
para que se active
y se vaya a producción,
¿no?
No es que la persona
va a ir a escribir scripts
para que se vaya a producción,
pero tal vez
le podemos poner
una traba ahí en el medio
por una cuestión
de compliance,
algunas empresas
necesitan que
esto esté probado
en un entorno
o que se cree un ticket
o que tenga aprobación
de un humano
antes de que vaya a producción,
entonces por eso digo
que eso de automáticamente
deployar a producción
en realidad
o desplegar a producción
en realidad
hay que tomarlo con piensas
y hay que verlo
en el caso a caso.
Pero la idea acá
es que reducir
lo máximo que podamos
la intervención humana
y que todo esto
desde poner el código
en nuestro repositorio,
subirlo al repositorio,
que se testee,
que se mergee,
que se suba
a un repositorio
de ya sea una imagen
de Docker,
un War,
lo que sea,
o un MPM,
RIM,
RUN,
build,
y se vaya a producción,
todo esto es CICD.
Así que vamos 15 minutos,
nos quedan 5 minutos
para hacer una pequeña demo,
¿sí?
Y acá yo tengo un repo,
vamos a achicar un poquito,
agrandar un poquito
la letra,
ahí se ve perfecto.
Yo acá tengo un repo
súper simple,
¿sí?
Donde yo solamente
les quiero mostrar
cómo puedo poner
este código en producción.
Acá tengo dos manifiestos
de Kubernetes.
Kubernetes es un servicio
para orquestar contenedores,
no viene el caso
en el momento,
pero vamos a hacer
un pequeño cambio
y yo acá tengo
una imagen de Nginx,
que es un servidor web
y tengo un archivito
Nginx HTML,
¿sí?
Donde tenemos,
por ejemplo,
hola midu conf.
Si yo agarro esto
y lo edito,
vamos a hacerlo
en vivo esto,
¿no?
Vamos a hacerlo
directamente acá.
Hola midu conf,
vamos a ponerle
hola midu conf,
vamos
peladoner.com,
vamos a peladoner.com,
vamos todos
a peladoner.com.
Por favor,
no me tiren el sitio.
Bueno,
vamos a poner la P,
buenísimo,
vamos a cometer
estos cambios,
¿sí?
Y los voy a subir
directamente a main branch,
obviamente en el caso,
un caso real,
yo tendría que hacer
un pull request
que vaya a otra persona
que la otra prueba
y que se hace el testeo
y todo eso,
pero como estoy yo solo acá,
nadie me quiere,
midu se fue a tomar un café,
me dejó solo,
entonces yo acá estoy,
voy a meter este main,
este cambio directamente en main,
si vamos a comitear.
Que conste que es mentira,
que estoy aquí vigilando.
Ah, bueno,
sí,
puede ser un logrograma esto,
no lo sabemos,
pero bueno,
gracias.
Entonces,
esto lo que va a hacer
es disparar,
¿sí?
Un pipeline automatizado,
esto nuevamente,
pequeño,
pequeño,
bayas tengo,
estoy usando harness
que es la empresa
donde yo trabajo,
pero pueden hacerlo
con cualquier herramienta
y acá automáticamente
cuando yo mergeo,
fíjate que
va y se crea el archivo,
¿sí?
Se descarga,
se descarga el demo,
bueno,
lo hizo demasiado rápido
y ahí está haciendo el deploy.
Yo en mi máquina,
acá tengo un,
un clúster de Kubernetes
corriendo en mi máquina
y acá se va a aplicar,
a ver si ya lo vio,
a ver si lo hizo,
sí,
ahí se hizo el cambio,
¿sí?
Y si yo ahora abro,
esperen un segundo,
no se vayan,
acá estoy con usted,
vamos a hacer un mini queue
service,
no se vayan,
acá estoy,
no importa que no esté mostrando
la pantalla,
ya lo sé,
no se hagan problema,
se me fue el,
¿cómo era?
Mini queue service,
ahí está,
y si ahora abro,
ahí está,
hola a todos,
hola a Mido Conf,
vamos a pelado,
vamos todos a pelado enero.com,
vamos a hacerlo de nuevo
porque seguramente no me creen,
aparte me quedan tres minutos,
vamos a hacerlo de nuevo,
vamos a ir nuevamente acá,
vamos a editarlo otra vez
y vamos a poner
hola a Mido Conf,
Mido
es un holograma,
vamos a guardar,
vamos a comitear,
vamos a ir directamente a la main branch otra vez,
vamos nuevamente acá al pipeline,
vamos a ver cómo se ejecuta,
ahí viene,
se está corriendo este nuevo pipeline,
esto lo que va a hacer entonces es descargarse el código,
correr un pequeño script,
que lo único que hace es hacer kubesity del apply,
o sea,
aplica el cambio,
ve el cambio que yo hice en el archivo,
y lo deplo ya en mi clúster de Kubernetes,
que lo tengo corriendo en mi máquina,
y ahí está,
hizo el apply,
si vamos acá,
vamos a refrescar
y vamos a ver si Mido es un holograma o no,
Mido es un holograma,
efectivamente,
así que excelente,
eso es lo que les quería mostrar,
vamos a entonces recapitular rápidamente,
me quedan dos minutos,
así que recapitulemos,
un repo simple que contiene un manifiesto de Kubernetes,
me permitió a mí hacer un cambio,
y directamente ponerlo en producción,
simplemente haciendo un merge,
obviamente el desarrollador tiene exceso absoluto,
para cambiar y hacer el deploy,
fíjense que yo no hablé con ninguna otra persona,
yo no tuve que pedirle permiso a nadie,
para poner mi código en producción,
yo simplemente hice un cambio,
hice un main,
y listo,
obviamente podemos hacer cosas,
podemos configurar el repo,
para que no se pueda mergear directamente a main,
o no se pueda comitir directamente a main,
que requiere aprobación,
eso se puede hacer,
pero va a nivel,
digamos,
de la configuración de la herramienta,
el desarrollador tiene acceso absoluto,
para cambiarlo a hacer el deploy,
en el caso que haya algún cambio,
fíjense como yo hice un cambio,
lo volví atrás,
y se fue directamente a producción,
obviamente el deploy se hace automáticamente,
por cada commit,
y se aplican los cambios al clúster,
y no hubo nada de interacción humana,
así que bueno,
¿qué concluimos con todo esto?
El CIS admin,
o el equipo de operaciones,
pasó de ser el que dice no,
al que dice copo,
vamos de nuevo,
el CIS admin pasó de ser el que dice no,
al que dice como,
ahora se confía más en el desarrollador,
y se le da más responsabilidad,
o sea,
yo ahora,
creo que el desarrollador no va a tener problemas,
no va a poner cosas malas en producción,
y también le damos más responsabilidad,
o sea,
está bien,
te doy el permiso para que vos hagas lo que quieras,
pero a la vez,
si se te rompe,
también vos podés volver atrás,
no me tenés que estar llamando a mí,
la velocidad es todo,
aunque hay que balancearlo con la estabilidad,
hay que balancearlo con la seguridad,
y el monitoreo es vital,
es vital tener unas herramientas que nos avisen si se cae algo,
en este caso yo funcionó todo bien y no puse ningún monitoreo,
pero tranquilamente podríamos poner alertas,
que se cae el sitio que me llegue,
una alerta al teléfono para volver atrás,
incluso podemos automatizar el volver atrás en el caso de que se caiga,
pero obviamente no tenemos tiempo,
y la automatización es mucho más importante de lo que parece,
parece que no,
parece que es mucho tiempo,
pero no es tan así,
así que bueno,
no sé si hay tiempo para preguntas,
pero visiten mi sitio,
peladoner.com,
ahí están todas mis redes sociales,
estoy en Twitter,
en Instagram,
en GitHub,
en YouTube,
síganme,
cualquier cosa,
y voy a estar seguramente,
ahora en Buenos Aires para enerdearla,
con Mido vamos a ir a correr,
y Mido ya me ha prometido que va a ir a correr despacito conmigo,
porque yo voy a estar con las piernas cansadas,
porque corro la maratón,
una semana antes.
Ah,
una semana antes,
hostia,
bueno,
no,
pero igualmente tú corres un montón,
tío,
corres,
cuando haces tiradas,
haces tiradas largas,
es que te picas un verdadero maratón,
es espectacular,
y se te nota,
se te nota un montón,
que se nota que está bien fuerte,
gracias,
gracias,
pelado,
lo malo de que has dejado tu página web,
es que te la hemos tirado,
y no te has dado cuenta.
No,
es imposible eso,
no te creo nada.
Bueno,
la hemos dejado ahí en blanco,
bueno,
ahora porque se ha recuperado,
pero la hemos tirado antes.
No,
no me llegó ninguna alerta,
yo no me hubiera llegado la alerta del teléfono.
Muy bien,
la monitorización es vital,
bien dicho.
Oye,
Pablo,
me he quedado con mucho,
o pelado,
como quieras,
nos vemos en nerdearla,
allí charlamos,
vamos a correr,
pero me he quedado con muchas ganas de muchas cosas que has hablado,
primero yo de enseñarte un poquito de javascript,
y tú de enseñarme más de devops,
así que un día te pasas aquí con calma,
y estamos dos horas cacharreando,
¿te parece?
Dale,
y quiero también el peluche ese de el This is fine,
porque obviamente lo tengo tatuado acá.
¡Ostras,
qué bueno!
¡Qué grande!
Así que bueno.
Pues voy a hacer algo para conseguirlo,
pelado.
Bueno,
amigo,
muchas gracias,
nos estamos viendo,
y muchas gracias por todo este evento,
la verdad que es increíble,
te felicito.
Nada,
gracias a ti,
y muchas gracias por clavar el tiempo además,
y hacerlo en un ritmo y una forma espectacular.
Muchas gracias,
te aprecio,
y nos vemos prontito.
Cuídate,
pelado.
Chao.