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

Ranthas #4591 Mar '20

Nueva feature: registros en 2020.

Wow.

eisenfaust #4592 Mar '20

No puedes echar de menos lo que no sabes que existe.

1 1 respuesta

eXtreM3 #4593 Mar '20

#4592 cómo puedes saber que algo no existe?

1 respuesta

aren-pulid0 #4594 Mar '20

#4593 Porque sabes que no lo sabes

B

[Borrado] #4595 Mar '20

Si logras convencer a todo el mundo de que eso no existe, yo creo que técnicamente deja de existir.

afhn #4596 Mar '20 Guardia Imperial

Pero para que algo deje de existir tienes que demostrar que no existe, mientras tanto, ni existe ni deja de existir hasta que alguien demuestre que existe o que no existe. ES DIOS!!!!!

aren-pulid0 #4597 Mar '20

No se si esto tiene cabida aqui pero tengo muchas dudas sobre implementar una pipeline de CI y no se si me sobra pasos o si me faltan.

Se codifica y se realizan tests en el entorno del desarrollador, este hace un push en su rama y alguna herramienta imagino que jenkins o algo similar a través de un hook lee el cambio en la rama del repositirio y lleva los cambios al entorno de testeo, donde corre los tests y si pasa los tests todo ok ¿no?. Osea haría un merge a la rama principal o bueno npi...

¿Y para el CD se pasaría de ese entorno de testeo repitiendo un proceso similar al de desarrollo?

5 respuestas

Lecherito #4598 Mar '20 A toda leche

#4597 Si

HeXaN #4599 Mar '20

#4597 No.

Markitos_182 #4600 Mar '20

#4597 Tal vez.

aren-pulid0 #4601 Mar '20

Lo que mas me lía es el tema del git y como se organiza con la herramienta que automatiza los procesos, asique si me pudierais dar un par de pistas sería de mucha ayuda, que soy un pobre pajeet sin experiencia laboral aún

1 respuesta

r2d2rigo #4602 Mar '20 Inocente

#4597 yo uso master/staging/dev:

dev es el salvaje oeste, ahi vamos commiteando segun acabamos features porque tenemos un workflow bastante rapido.
cuando QA va teniendo tiempo de probar cosas, pull request a staging con code review, correr tests, etc.
cuando QA da el OK, merge a master y publicar en live.

YMMV, hay varias cosas que pueden cambiar o mover a dev, etc.

1 1 respuesta

Lecherito #4603 Mar '20 A toda leche

Siempre en mainline y no se commite meirda

JuAn4k4 #4604 Mar '20

#4601 Busca gitflow, para el flujo de desarrollo y ramas em git. #4602 echale un ojo a también para mejorar el proceso de release.

CI te ejecuta la build de los PRs, y te permite mergearlos si la build esta OK.

En la build se pasan los tests.

Al mergear se ejecuta la build en la rama destino, bien sea develop o master o release.

Las builds generan artifacts que valen para el pipeline de CD.

Lo puedes hacer con Jenkins, TravisCI, CricleCI, Gitubub Actions, etc.

1 respuesta

r2d2rigo #4605 Mar '20 Inocente

#4604 en mi caso tenemos 350 UI tests y ₁₂ builds (shared core del que sacamos 6 apps de iOS y 6 de Android) que no nos podemos permitir correr con cada pull request peque;o

B

[Borrado] #4606 Mar '20

#4597

Dev clona repo
Dev crea rama en local
Dev hace cambios en su rama
Dev pushea rama al repo
Dev crea un PR contra master
Travis prueba cambios de tu rama y da verde
Otros devs validan los cambios
Se genera un rama a partir de master donde se meten los cambios del PR
Se vuelve a probar todo esto en travis y da verde
Se mergea la rama de prueba finalmente en la rama master
Travis vuelve a lanzarse y da verde
Tus cambios han sido finalmente aprobados y fusionados. Enhorabuena.

1 1 respuesta

r2d2rigo #4607 Mar '20 Inocente

#4606 pull request directamente contra master, sin pasar por staging/UAT? Golpe de remo.

1 1 respuesta

B

[Borrado] #4608 Mar '20

#4607 El PR es contra master, pero en nuestro caso tenemos un bot que se encarga de hacer merge.... Los mantenedores del repo escriben "/bot merge [major|minor|patch]" y el botijo se encarga de crear un rama intermedia antes de pasar a master. Si todo va bien se acaba mergeando en master.

Tampoco me hagas mucho caso, porque del botijo no conozco mucho... igual me estoy comiendo pasos.

EDIT: El runbot da una aproximación del tamaño de la infraestructura montada... https://runbot.odoo-community.org/runbot (Darle al desplegable 'github.com/OCA/OCB' xD)

** Desde fuera, cuando se fusiona un PR ese PR quedar queda como "cerrado" no como fusionado. (una limitación que a ver si se resuelve jejeje)

1 respuesta

r2d2rigo #4609 Mar '20 Inocente

#4608 me refiero a que deberiais tener otra rama intermedia.

dev con lo ultimisimosiempre mergeado.
staging con lo que va siendo aprobado para la siguiente release.
master solo tiene lo que esta actualmente en produccion, si algo va muy muy mal siempre podreis hacer rollback desde ahi.

1 respuesta

B

[Borrado] #4610 Mar '20

#4609 Ten en cuenta que nosotros desarrollamos módulos para un software "padre" llamado Odoo. Nuestra forma de trabajar es en abierto y se confía en los revisores y en la infraestructura montada. Tenemos en casi todos los repos más de un 80% de "coverage".
Un PR no pasa hasta que no tiene el visto bueno de otros tres desarrolladores miembros del PSC del repositorio en cuestión, que son quienes en teoría han de velar por el buen funcionamiento y conductas.

La rama master en realidad no es una única, se nombra por version de Odoo: 12.0, 13.0, etc... y se trabaja al mismo tiempo en todas. Es un CI puro apoyado en un 'CD pipeline' de la hostia.

Lecherito #4611 Mar '20 A toda leche

Me llega una empresa haciendo gitflow y cuelgo la llamada

3 1 respuesta

B

[Borrado] #4612 Mar '20

#4611 mejor usbflow

B

[Borrado] #4613 Mar '20

Últimaversiónahorasíquesíentrgarya.zip

eisenfaust #4614 Mar '20

git flow y similares (hay workflows mucho mas complejos) pueden tener su uso. no todo el mundo hace webs de gatitos

pero por lo general trabajar con vcs implica trabajar con ficheros, lo cual de por si es de masillas, asi que tampoco vamos a ponernos a discutir ahora sobre ello

just write a doubly linked list that points to collections of .patch files bro

2 respuestas

eondev #4615 Mar '20 Rawe Ceek

#4614eisenfaust:
pero por lo general trabajar con vcs implica trabajar con ficheros, lo cual de por si es de masillas, asi que tampoco vamos a ponernos a discutir ahora sobre ello

Intuyo entoncse que conoces alguna alternativa

1 respuesta

eXtreM3 #4616 Mar '20

Cuál es el flow más potente para git?

1 respuesta

eondev #4617 Mar '20 Rawe Ceek

#4616 el de desu con su jeep por la ciudad

3

eisenfaust #4618 Mar '20

#4615 alternativa a que, a ficheros? es un tren que se perdio hace mucho ya. los sistemas operativos para secretarias ganaron la batalla

lo mas parecido seria hacer cambios en el runtime sobre un sistema basado en imagenes que no son mas que dumps de memoria. common lisp, smalltalk, forth, factor permiten este tipo de desarrollos

forth es un caso especial dado que fue pensado para ejecutarlo bare metal sin un sistema de ficheros, y el standard aun requiere compatiblidad con el uso de bloques de 1024 bytes como persistencia

1 respuesta

Kaledros #4619 Mar '20

¿Cambios en el runtime? Psch, aficionados... los trve devs vuelan el server por los aires y traen uno nuevo para cada commit.

Wei-Yu #4620 Mar '20

#4618 qué diferencia hay entre un dump de memoria y un fichero?

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales