Feda /dev/ - No Javascript allowed | Página 1976

aren-pulid0 #59251 20h

#59249 esto es en local y sí debería ser así pero ya lo ves xd

#59250 sí, porque hay gente que no son capaces de poner el prettier bien

1 respuesta

Konishi #59252 20h :psyduck:

Si a los compañeros no se les atraganta instalar python puedes probar con pre-commit

Wei-Yu #59253 20h

#59251 la pipeline nunca nunca toca el código fuente, me plantas algo así y te monto un pollo

p.s: este proyecto no lo había tocado aún y tiene husky pero mal configurado. Hay cosas peores como que está con vue 2 que lleva literalmente un año deprecated.

1 1 respuesta

aren-pulid0 #59254 20h

#59253Wei-Yu:
la pipeline nunca nunca toca el código fuente, me plantas algo así y te monto un pollo

quien ha dicho eso? porque para montar el pollo mira como te hubiese solucionado el problema con el que llevas 2 días

1

PiradoIV #59255 19h Brongster

Que os creéis muy guay con vuestros pipelines y vuestros pre-hooks, pero os hago un cambio en el index.php por SSH y no hay pull request que os salve.

5 1 respuesta

isvidal #59256 18h

#59248 que dices animal

1 respuesta

aren-pulid0 #59257 18h

#59256 yo he visto ambas, blocking si hay cambios del prettier y commits con el prettier

2 respuestas

Lecherito #59258 18h A toda leche

Si tenéis tanto tiempo como para pensar si le falta un espacio delante de la coma a un parámetro y mierdas del estilo, os falta trabajo real tbh

3

pantocreitor #59259 18h

#59255 Calla calla, que llevan los de dev ops haciendo pruebas con los pipelines en mi curro y desplegar es una odisea.
Les digo que si puedo tirar directamente de kubectl y me dicen que "oh no no, kubectl is a much more complex tool than the gitlab pipelines, you shouldn't do that"
Automáticamente he desplegado todo a manita y le he dicho a mi jefe que si se quejan los de devops ya saben que apéndice mío pueden meterse en la boca para que se me relajen un rato.

1 respuesta

Wei-Yu #59260 18h

#59257 que lo hayas visto no quiere decir que esté bien. La pipeline nunca puede mutar el código porque entonces lo que mergeas no es lo que has desarrollado. El riesgo nunca es cero.

Es muy muy muy mala práctica y no debería hacerse nunca. Mira que pocas veces me meto en blancos y negros pero este es uno de ellos.

1 1 respuesta

wdaoajw #59261 18h

#59259 eso es algo que no me parecería mal, pero si jodes algo te llame a ti el oncall.

Normalmente el oncall no se lo comen los devs, y por tanto hacer estás cosas no parecen tan locas, pero ponte tu a hacer debug de algo con todo cambiado a mano por un random, suerte

1 respuesta

Dr_Manhattan #59262 18h 4life

Se crea el mismo los problemas por usar un editor que no conoce ni el que lo creó

Miradme soy especial

pantocreitor #59263 18h

#59261 ni on call ni leches, es el entorno de desarrollo de nuestro producto. Entiendo que quieran trastear, pero cojones, que estoy desplegando un servicio en el cluster que necesitamos probar bastantes persoas, lo peor que puede pasar es... absolutamente nada.

En preproducción o producción de nuestro entorno tenemos 0 permisos en los clusters o máquinas para todo porque entiendo que es otro tema, pero en desarrollo que no me toquen los cojones y si quieren hacer pruebas que se monten un puto cluster en local y que prueben.

A ver, me toca los cojones porque cuando hay problemas a la hora de hacer un despliegue de una release los de devops se cagan encima y yo suelo ser uno de los que lo tiene que arreglar las cagadas.

1 respuesta

Wei-Yu #59264 18h

oh no no, kubectl is a much more complex tool than the gitlab pipelines, you shouldn't do that

lul

Lecherito #59265 18h A toda leche

Entre cambiar el código en la pipeline y el otro que no tiene pipelines en condiciones y hace deploy a mano se está quedando un hilo guapo.

Madre mía, en qué tipo de empresas trabajáis que no tenéis ni un guarro pipeline para hacer deploy de manera escalonada y por stages?

1 1 respuesta

pantocreitor #59266 18h

#59265 piplines hay y funcionan bien, hasta que viene el subnormal de devops que se cree que todo el mundo es inutil menos él, se lo carga todo y quiere que la empresa se paralice hasta que termine de jugar.

Coño, una aplicación vieja que tira en wildfly petaba cada 2x3, 4 días después seguía petando y nadie de devops sabía que coño pasaba.
Me meto, journalctl del servicio -> OOM... de verdad que no han visto el puto mensaje de OOM que se repite cada 3h mas o menos???
Que pasó??? que al de devops se le ocurrió cambiar la instancia a una con un core y 4gb de ram pero no cambió la configuración de la aplicación.
4 días petando y no tenían ni puta idea de que cojones pasaba... QUE ME CAGO EN TO SUS MUERTOS ME CAGOS

1 respuesta

wdaoajw #59267 18h

Si tienes inútiles en la empresa no es un problema de DevOps...

1 1 respuesta

aren-pulid0 #59268 18h

#59260Wei-Yu:
que lo hayas visto no quiere decir que esté bien. La pipeline nunca puede mutar el código porque entonces lo que mergeas no es lo que has desarrollado. El riesgo nunca es cero.

no digas tonterías por favor, la pipeline ejecuta lo que tendrías que hacer tú en local, es un guardarraíl para tontitos que no son capaces de hacer funcionar el husky/pre-commit o lo que sea y además de blocking te hago el favor de formateartelo, si lo haces bien te paso el check y no hay nada que formatear.

Y si hay conflictos, que venga el compañero y te diga que eres tonto, porque no tienes el precommit puesto y tiene que hacer fetch cada vez que haces un puto commit.

1 respuesta

pantocreitor #59269 18h

#59267 ya, con devops por lo que se ve lleva habiendo problemas mas o menos año y pico, desde que se fue el encargado de la tribe de devops que ese nota era una máquina. Subieron a uno que llevaba tiempo en la empresa pero es un manta y es el que hace las entrevistas a los nuevos, así que manta contrata mantas y así van

Kaledros #59270 18h

#59266pantocreitor:
hasta que viene el subnormal de devops que se cree que todo el mundo es inutil menos él, se lo carga todo y quiere que la empresa se paralice hasta que termine de jugar

Empresa de mierdaaa...

1

PhDfailer #59271 18h

Si tenéis gitops y haces un kubectl apply, estas desincronizando el estado del cluster con la fuente de verdad que es el codigo de infra.

Los cambios solo deberian ser a traves de la pipeline con un commit o PR a ese repo de gitOps.

Es el equivalente a crear un recurso por consola de aws o azure en lugar de usar la pipeline de terraform.

Si la pipeline es una mierda o lenta, es otra cosa, pero meter cambios a mano en la infra por los devs es un error, si es un equipo grande es un caos.

Si no teneis gitOps y estais usando kubernetes, que coño estais liando?

2 1 respuesta

Fyn4r #59272 17h Inocente

Si es que al final un script que abre ssh, copia codigo y reinicia el servicio es inmejorable.
PHP 2004 was right

aren-pulid0 #59273 17h

#59271 de hecho lo más probable que tengan la reconciliación automática puesta y se haya vuelto a desplegar lo que hay en los manifests/chart y/o que hayan quedado recursos huérfanos por ahí dependiendo de la config del Argo/Flux

1

Kaledros #59274 17h

https://fortune.com/2024/09/24/amazon-employee-survey-rto-5-day-mandate-andy-jassy/

Otra que no se podía saber

2 respuestas

fehnd #59275 17h

#59268 Sinceramente no sé si esto es un bait o que.

Una pipeline nunca debería hacer commits sobre ramas propiedad de alguien que no sea la propia pipeline

Check de formateo y si te arreglo algo te hago commit a la rama? -> MAL
Check de dependencias y si tengo algun update, creo rama, updateo, hago pullRequest y que pase la CI con el nuevo valor? -> BIEN

Ejemplo -> https://github.com/renovatebot/renovate

#59263 Por experiencia propia, cuando hay ese tipo de reticiencias, acaban teniendo que ver con políticas de permisos que se han establecido en base a una cagada tocha por "dejar hacer". Y al final muchas políticas se aplican a todos por culpa de uno. Es una mierda, y estoy contigo en que el entorno de desarrollo debería ser más facil de cacharrear por parte de los devs, pero tiene pinta de que falta confianza.

#59274 Amazon dice que no entiende porque sus empleados son infelices si les están obligando a ser felices y no quejarse yendo a la oficina

1 respuesta

aren-pulid0 #59276 17h

#59275

#59275fehnd:
Sinceramente no sé si esto es un bait o que.

Una pipeline nunca debería hacer commits sobre ramas propiedad de alguien que no sea la propia pipeline

Check de formateo y si te arreglo algo te hago commit a la rama? -> MAL
Check de dependencias y si tengo algun update, creo rama, updateo, hago pullRequest y que pase la CI con el nuevo valor? -> BIEN
Ejemplo -> https://github.com/renovatebot/renovate

Hablo de formateo, el tema de actualización de dependencias es completamente otro caso de uso, y sí, obviamente el commit es en la misma rama, esta pipeline es parte del CI (checks) de una pull request.

1 respuesta

fehnd #59277 17h

#59276 Buah, pues la verdad es que lo veo un poco turbio, que puede que esté todo en mi cabeza y luego va fino, pero me chirría mucho

1 respuesta

aren-pulid0 #59278 17h

#59277 es lo que le decía a Wei-Yu, solo hace lo que haces tu en local, con la misma config (.prettierrc), en vez de ser un blocker, lo conviertes en una automatización, que además ni debería saltar a no ser que tengas el prettier mal configurado o estes haciendo alguna cosa rara.

1 respuesta

GenBe #59279 17h

Que interesante todo, me gusta.

fehnd #59280 17h

#59278 Supongo que tiene que ver más con el tema de asumir que algo si sale mal a nivel de formateo, ya lo arreglará la pipeline, como que le quitas la responsabilidad al dev de hacer las cosas como toca porque a no ser que sea una soberana barbaridad, te lo va a manejar bien. Por poner un símil, es como cuando algún dev suelta la de "bueno, si pasa algo raro ya lo mirará QA" solo que QA es un departamento físico y no una pipeline.

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales