El otro día di una opinión y la gente se enfadó.
Queridos programadores, os voy a mandar una carta, ¿vale?
Queridos programadores, saber hacer despliegue a producción
no es algo que solo los DevOps deban saber.
No es algo místico o que solo unos elegidos deberían atesorar ese proceso
como yo sé hacer el despliegue y nadie más debe saber
cómo se hace un despliegue a producción.
Es muy difícil que una organización pueda ser ágil
y esté entregando software de forma continua
con ese nivel de dependencia donde me enganito
esa única persona es la que puede hacer ese proceso de despliegue a producción.
Imagínate que se mueren.
Pues nada, ya no se puede desplegar
porque no está documentado tampoco, a tomar por saco.
El tema, los silos de conocimiento siempre, siempre son malos.
Siempre.
No entiendo a alguien que me lo rebata, de verdad.
O sea, me sabe mal, pero los silos de conocimiento siempre son malos.
Son peores incluso las limitaciones que nos ponemos nosotros,
que nos autoimponemos,
como las barreras de lo que debe y no debe saber una persona.
Es que alucino de que hay gente que me dice
es que un frontend nunca debería hacer un despliegue a producción.
O sea, yo no estoy diciendo que un frontend deba saber
toda la infraestructura que tenga detrás,
pero que no sepa ir a un pipeline y darle un botón.
O que si está en rojo, más o menos ver dónde está el error.
O poder leer dónde están las métricas.
O sea, ha hecho un cambio en el código y empieza a petar errores 500,
poder ver dónde está el error.
¿De verdad eso no lo puede hacer un developer?
Ya no digo un frontend.
Frontend, backend o lo que sea.
¿De verdad?
Porque es que esto me lo estaban rebatiendo.
Lo más grave, y os lo voy a decir ahora,
hacer rollback, deploy, saber leer métricas,
entender la escalabilidad de nuestras soluciones,
del código que hacemos,
automatizar procesos,
todo eso no significa que,
porque esto también me lo ha dicho,
es que cada vez pedís que la gente sepa más cosas.
Es verdad.
La gente cada vez se pide que se sepa más.
Pero no me refiero a lo que tienes que aprender desde el minuto cero.
Me refiero a cuál es tu objetivo,
de dónde tienes que crecer en tu vida laboral como desarrollador.
En el minuto cero no te estoy pidiendo esto,
no te lo digo yo,
pero que veas a crecer,
de saber cómo se hace un rollback en tu empresa,
no me parece traumático.
Me parece importante.
La independencia es clave.
No sé.
O sea, es que es incuestionable.
Las ventajas que existen de que cualquier desarrollador en una empresa
sea capaz de hacer esto,
a no tener que depender de gente que puede estar o no está.
No todo es código en programación.
Y esto me sabe mal,
porque hemos infantilizado el mundo de la programación
en cuanto a que le decimos a la gente,
le damos una palmadita en la espalda,
le decimos,
no, no, no, no.
Tú solo tienes que hacer componentes de React.
Tú siéntate ahí,
¿vale?
Tu Tailwind y ya está.
A ver,
no se trata de eso.
El código que generamos,
si no lo llevamos a producción,
no sirve para nada.
O sea,
no todo es código.
Es que hay cosas que no tienen nada que ver con el código.
Y se trata de saber si es escalable,
saber documentar,
testing,
incluso aportar ideas,
la experiencia de usuario.
Es que hay un montón de cosas que no todo es código.
Cago en la leche.
El software va a veces mucho más allá.
Y no hace falta que seas experto en todo,
¿vale?
Pero es vital que para poder crecer,
pues que el equipo cada vez sea más autónomo.
Y los equipos cada vez son más autónomos e independientes,
justamente cuando cada persona,
cada perfil crece.
Os voy a decir lo que me da más pena de todo esto.
Mucha gente me habla de DevOps,
de DevOps,
¿no?
Y me da mucha pena de cuando se habla de DevOps,
porque la gente lo ha entendido mal.
La gente me dice,
es que tú lo que me estás pidiendo es que tengo que ser DevOps.
Y es que ser DevOps es una cosa que nos hemos inventado.
DevOps no era un rol,
era una filosofía,
una metodología.
Es algo a lo que deberíamos aspirar como culturalmente,
ya no solo a nivel de empresa,
sino personalmente.
Lo podéis ver en la Wikipedia por si nadie se lo cree.
Es prácticas que te ayudan a que el desarrollo de software
sea lo más rápido,
escalable,
fiable,
que tenga entrega continua,
y todo esto.
Y es justamente uno de los pilares de desarrollo de software ágil.
No es un rol.
Lo hemos creado nosotros un rol.
Nos hemos inventado un rol para esto porque no éramos capaces culturalmente
de meter esto en el mundo de la programación.
O las empresas no han sido capaces de instaurar esta cultura
y por eso se han visto forzados en esto.
Y justamente lo decía Magic Paul,
que gracias Magic Paul por decirlo.
Magic Paul dice,
yo soy DevOps y tenemos como filosofía transmitir conocimiento
y por ende independencia.
Y me alegro un montón,
porque es que justamente es eso.
Una persona que ahora mismo sea DevOps,
el rol de DevOps debería ser de líder
para justamente transmitir estas metodologías a todo el mundo
e instaurar que la gente,
los desarrolladores,
sean lo más independientes y autónomos posibles.
Eso, de eso se trata.
Entonces, por favor,
no volváis a decirme,
es que me lo han dicho en Twitter unas cuantas veces,
gente que yo alucino,
gente que me dice que es senior.
Pues tío, ¿qué está pasando aquí?
¿Qué está pasando en el mundo de la programación?
Y todo esto viene por este meme.
Esto en programación parece broma,
pero es una anécdota.
Junior, ¿dónde está la documentación?
Que esto nos pasa muchas veces, ¿no?
Que muchas veces, pues preguntamos, ¿no?
¿De dónde está la documentación?
Entonces el senior te dice,
yo soy la documentación.
Y entonces decía aquí alguien,
el perro hunter este,
el código bien escrito se documenta solo.
A ver,
el código bien escrito se documenta solo,
eso es otra mentira que se repite mucho,
porque nos encanta, ¿no?
Porque el código bien escrito se documenta solo,
no es verdad del todo.
Es el código bien escrito,
que además está lleno de test,
y que además tiene una documentación,
y entonces entiende bien.
Yo pensaba que digo,
bueno,
¿será que le ha hecho en broma y tal?
O que le ha puesto en comillas porque no era literal.
Y digo,
pero no todo en programación es código.
Por ejemplo,
¿cómo desplegar un servicio o hacer un rollback?
¿Dónde se ven las trazas en error?
¿Por qué no puedo levantar el servicio en local?
Una mínima documentación.
Y dice,
eso parece más de procesos,
cosas que usualmente,
los devs no suelen ver ni enterarse.
¿Cómo que un dev no suele enterarse
de cómo desplegar un servicio o hacer un rollback?
¿Dónde se ven las trazas si tienes un error?
¿Por qué no se puede levantar un servicio en local?
O sea,
los devs no tienen que saber levantar un servicio en local.
No sé si estamos tontos o qué nos pasa.
Mira,
¿cómo desplegar un servicio o hacer un rollback?
Eso le toca al DevOps.
Mira,
de verdad,
basta ya de decir tonterías,
infantilizar,
el tema del desarrollo de software.
Es una mentira,
que luego la gente llega a las empresas,
estas cosas se las creen.
Oye,
que está muy bien,
que si al final,
el cómo desplegar,
¿cómo desplegar un servicio?
No el cómo se despliega internamente el servicio
en la infrastructure y tal.
¿Cómo desplegarlo?
O sea,
¿cómo llevar mi código a producción?
En la vida real,
a no ser que vuestra empresa sea chunguilla,
interesaos por cómo desplegar vuestro código.
¿Qué pasa si hay un error?
¿Cómo podéis hacer un rollback?
Si no hay un rollback,
oye,
¿cómo podéis crear uno?
Todo este tipo de cosas.
¿Cómo ver trazas si hay un error?
Dice,
todo debería estar en ese TDout,
que me hace gracia.
Todo debería estar en ese TDout.
Vale,
si está en un servidor,
¿cómo lo ves?
Ah,
no,
eso otra vez el DevOps.
O sea,
que dependéis siempre del DevOps.
Y el DevOps,
que la gente se ha inventado que es un roll,
que está bien,
que existe de verdad,
porque yo también he trabajado con DevOps,
pero al final,
en realidad,
no era un roll.
Y la idea es que una persona,
una persona que se considere desarrollada de software,
no lo va a saber desde el minuto cero,
pero es importante para vuestro crecimiento
que os intereséis por estas cosas,
porque estas cosas son las que van más allá.
Así que no sé.
Esto es un poco un mensaje,
porque además hay un montón de comentarios en esta línea
y a mí me da pena,
porque no ayudan a no solo profesionalizar,
sino a crecer en el mundo del desarrollo del software
y seguimos dejándolo como,
no,
no,
el frontend solo componente,
es el no sé qué,
el backend,
pues solo hacer sus APIs y tal.
Y no funcionan así las cosas,
¿vale?
No funcionan así las cosas.
Esto también aplica,
el único que debe ser de negocio es el Product Owner.
Totalmente de acuerdo.
Deshora,
pero me estás entendiendo mal,
porque dice,
estoy de acuerdo contigo,
pero en empresas grandes,
donde hay equipos encargados de esto,
de gestionar AWS,
Artifactory,
bases de datos,
pues terminas por no estar al día de todo
y al final te pierdes.
Vamos a ver,
pero eso es,
eso me lo ha dicho mucha gente también,
pero es que eso está mal interpretado.
Yo no digo que tengas que saber de todo,
cómo tienes que gestionar AWS,
Artifactory,
todas las bases de datos y tal.
Lo que quiero decir es que,
desde tu código,
hay que crecer hacia afuera
y tienes que saber cómo desplegar tu código.
Fíjate la diferencia entre
saber cómo desplegar tu código
a gestionar AWS.
Yo no digo de que tengas que saber gestionar AWS
ni que tengas que saber de todos los costes,
ni todo lo que hace un SRE,
ni lo que hace el supuesto DevOps y todo esto.
Y claro que hay roles
que se van a dedicar mucho más,
de forma mucho más profunda
en este tipo de cosas,
pero el saber gestionar,
saber desplegar un servicio,
saber ver si el código que has llevado
a producción está petando,
eso que, o sea,
tú desplegas,
pero esperas que te venga el DevOps
o el SRE
a decirte que tu código
está dando errores 500,
eso parece normal,
no tiene ningún tipo de sentido.
El tema de automatizar,
hacer lanzamientos a producción más rápidos,
hacer que tu build cada vez sea más rápida,
¿eso te va a venir el DevOps
de que tu deploy,
de que tu build de Vercell tarde más?
O sea, el DevOps es el que te va a tener que decir.
El SRE te tiene que decir,
yo que sé,
que la tasa de errores que tienes
en la generación de las nuevas versiones
de tu código
cada vez tienes más errores.
No, no te lo va a decir.
Eso lo tenéis que decir,
lo tenéis que hacer tú.
O lo podéis hacer de forma conjunta,
que de eso se trata.
O sea, de lo que se trata también
es que trabajes con el DevOps
y con el SRE,
que van a saber más que tú,
obviamente,
en gestionar bases de datos
y todo este tipo de cosas.
Y al ayudaros,
que tú sepas un poco de lo suyo
para que tú seas más independiente
y autónomo.
Que es que muchas veces
cuando digo estas cosas,
la gente se cree
que lo que se está pidiendo
es que seas un SRE.
Y es que un Site Relability Engineer
hace muchas cosas más profundas
que el saber cómo se despliega un servicio.
Que lo único que os quiero decir
sobre este salseo
es que miréis más allá
de vuestro teclado.
El saber cómo se despliega algo,
o sea,
es que me parece básico.
En mi empresa todos sabemos todo.
Otra cosa es que cada uno
desempeñamos un rol concreto
y si alguien no está,
rotamos.
Eso me parece increíble
y me parece súper interesante.
El hecho de que al final
se llegue a ese nivel
de madurez
en el que tú ya sabes
un poco de todo
y que no eches en falta
a otra persona,
eso es como un objetivo
al que puedes llegar
que es genial, ¿sabes?