Feda /dev/ - No Javascript allowed

#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.

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.

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

#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.

#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

#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.

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?

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

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?

#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

#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