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

PhDfailer #59341 3h

#59339 Es muy diferente una startup pepito de un proyecto core que genera miles de millones dentro de una multinacional.

Lo cierto es que la mayoria de veces se tiende a sobreingenieria.

1 respuesta

isvidal #59342 3h

#59336 obvio que para hacer releases de packages tienes un comando, que ejecutas manualmente, que hace un commit con la versión nueva blablabla

No tiene nada que ver con un CI tirandote commits de linteo en tu rama en activo

isvidal #59343 3h

#59339 vamos a ver, el equipo de SRE’s de mi empresa, con 1500 empleados, fintech, valorada en 5000 mil millones.

El equipo de sre se encarga, efectivamente, de la infrastructura a nivel global y de apoyar a los devs en sus pipes, hay una división propia de ciber seguridad.

Pero si os creeis que los de SRE se meten con equipo de web (90+ personas) a configurar los pipes de linteo, types o de como correr los tests…

Entonces si, trabajais en empresas paco, supongo que tambien teneis equipo de QA.

2 respuestas

PhDfailer #59344 3h

#59343 de los de front pasamos todos...

Wei-Yu #59345 3h

5000 mil millones

se lo paso a la pipeline para que te lo corrija

1

aren-pulid0 #59346 3h

#59340

Te lo voy a explicar muy fácil:

Lo que tu dices:
1 - Haces código
2 - Haces commit (tu pre-commit se lanza con la config del .prettierrc y hace el format)
3 - Push
4 - CI

Lo que yo digo:
1 - Haces código
2 - Haces commit (tu pre-commit se lanza con la config del .prettierrc y hace el format)
3 - Push
4 - CI

Lo que yo digo (2):
1 - Haces código
2 - Haces commit (tu pre-commit NO se ha lanzado/tienes una configuración custom de prettier que no es la del repo)
3 - Push
4 - CI (El prettier formatea con el .prettierrc que hay en el repo y commitea en la misma rama)
5 - Commit en la rama con el código formateado de forma correcta
6 - CI

Beneficicios: Independientemente de te funcione o no el lintern y/o tu configuración en local te aseguras que el standard de el código sigue estando y ADEMÁS, evitas tener que hacer el format en los casos:

1 - No lo tienes bien configurado
2 - No está hecho el pre-commit

El que problema que tu dices: Te va a pasar siempre, esté o no esté la automatización del commit. Atento, @Wei-Yu, de nuevo, atento, lee despacio. Repito, lee despacio:

El prettier usa la misma configuración de local (.prettierrc) y en la pipeline, solo hace "prettify" sobre los ficheros con modificaciones, el resultado de la pipeline es el mismo que si lo hicieras en local. Si te rompe el código, los test te van a fallar.

Te reto de verdad a que me pongas un problema REAL

Cambiar el código fuente de forma automática parece que no suena suficiente absurdo

go fmt?
cargo format?
deno fmt?

1 respuesta

wdaoajw #59347 3h

#59343 #59341 claro que los de plataforma no se meten hasta el ultimo detalle ni mucho menos, de hecho lo ideal es que sea todo lo self service posible.

Pero self service no significa tampoco que cada uno se monte sus pipelines de forma independiente porque además implican temas de permisos, costes, security, etc

1

r2d2rigo #59348 3h Inocente

Que intensitos estamos para ser viernes no?

1 respuesta

HeXaN #59349 3h

#59348 Y espera que no saquemos a relucir el cómo se tienen que hacer los commits, el mensaje que deben llegar y blablabla.

1

eondev #59350 2h Rawe Ceek

Imagina no poner el linter en el repo para que lo tengan todos igual

Leagrove #59351 2h

Nombre del proyecto(numero) , tarea , una nota informativa diciendo si es un fix /create/ update y una nota descriptiva de lo que has solucionado / problema
Hay algo que debería añadir más o que no estoy haciendo bien cuando escribo el commit?
Por mejorarlo y aprender, muchas gracias

1 respuesta

Wei-Yu #59352 2h

#59346aren-pulid0:
Lo que tu dices:
1 - Haces código (tu autoformat en save se lanza)
2 - Haces commit
3 - Push
4 - CI

FTFY.

Sobre precommit sí/no; el precommit no te hace push instantáneo y es el dev el que lo tiene que configurar y mantener porque así quiere su setup. No institucionalizas que la pipeline mute el código. Son dos cosas muy distintas.

#59346aren-pulid0:
Si te rompe el código, los test te van a fallar.

Los tests quizás fallen; por eso he hablado de runtime.

El beneficio que pones es absolutamente nimio a cambio de introducir un riesgo que, simplemente, no es necesario. Si quieres ignorar o ridiculizar el riesgo adelante. Ejemplos ya te he puesto; si estos ejemplos no cumplen con tus estándares para considerarlos como algo real es tú problema, no el mío. No tengo por qué pegarme con nadie porque no voy a comerme ninguna incidencia ni voy a corromper datos de forma silenciosa ni me va a pasar absolutamente nada.

1 respuesta

HeXaN #59353 2h

#59351Leagrove:
Nombre del proyecto(numero) , tarea

No sé si esto lo haces a mano, pero nosotros lo tenemos automático. El resto es similar a cómo lo hago yo.

Kaledros #59354 2h

Si un linter en el pipeline te jode un test te lo joderá igual en local y eres un MANDRIL por tener un linter que cambia lógica en vez de formato.

1

Lecherito #59355 2h A toda leche

Pues yo sudo de los linters

5 1 respuesta

aren-pulid0 #59356 2h

#59352

#59352Wei-Yu:
FTFY.

Sobre precommit sí/no; el precommit no te hace push instantáneo y es el dev el que lo tiene que configurar y mantener porque así quiere su setup. No institucionalizas que la pipeline mute el código. Son dos cosas muy distintas.

Si eso me parece perfecto, como sea.

#59352Wei-Yu:
El beneficio que pones es absolutamente nimio a cambio de introducir un riesgo que, simplemente, no es necesario

pero que riesgo?? Que no tienes garantías de que el resultado sea el mismo en la pipeline que en local?? Lo tienes entonces para los tests??

EDIT, ahora entiendo lo de las garantías

spoiler

Y si no te fías de que el formatter para que lo usas? Porque lo tienes en el auto save? Cada vez que guardas el fichero testeas que todo lo que te ha formateado en el save funciona??

Absurdo.

Yo lo dejo aquí.

eondev #59357 2h Rawe Ceek

#59355 yo tb xD. Cambiamos el código que hay que tocar y ya. No se reformatea nada

2

PiradoIV #59358 13m Brongster

Lo suyo es poner una guía de estilo de código. Si alguien la rompe de manera reincidente, se le despide y ya está.

No hay que delegarle la tarea a un linter, ni necesitas una cultura DevOps. La mente colmena no se forja con un pre-hook, todos tienen que escribir bien y ya está (código o prosa). Si no saben ni seguir una guía de estilo, no saben nada de la empresa y poco valor van a poder aportar.

Mis 2 duros.

PD: Es bromita, haced lo que os salga del culo, buen finde ;***

1 respuesta

Dr_Manhattan #59359 6m 4life

#59358 lo de la guía de estilos lo comentó el top 0000.1%

1 respuesta

PiradoIV #59360 4m Brongster

#59359 El top 0.000001% apenas sabe juntar tres palabras en una frase, como para hablar de guías de estilo.

#freedesu

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales