cómo mantenerse eficiente cuando una construcción casi siempre se rompe

25

Trabajo en un equipo de tamaño medio que comparte el mismo código fuente y, aunque tengo una integración continua, pero como todos tenemos que trabajar en la misma rama, la construcción casi siempre se rompe.

Como también tenemos una regla, que se ha introducido recientemente para aliviar las compilaciones rotas, que establece que a nadie se le permite registrarse mientras que la construcción es roja.

Habiendo dicho eso, durante un día todos tienen un puñado de ventanas de 10-15 minutos donde permitimos registrarnos.

Y a medida que el equipo crece, las ventanas de las oportunidades de registro se reducen aún más. Eso obliga a los desarrolladores a acumular sus cambios localmente, lo que resulta en un conjunto de cambios más grande que es aún más difícil de garantizar que los cambios no rompan nada. Puedes ver el círculo vicioso.

¿Qué me puede recomendar para que pueda seguir siendo eficaz trabajando en un entorno como este? Además, tenga en cuenta que soy un desarrollador, no un administrador, y no puedo cambiar mucho el proceso o el comportamiento de otras personas.


fuente
8
¿Por qué no puedes tener sucursales?
Zavior
66
aparente solución sería la de configurar su rama "personal" y comprometerse en ella, y luego integrar esa rama con uno que trabaja en equipo
mosquito
@Zavior tener una rama implica una complejidad adicional y, por lo tanto, un trabajo adicional: la fusión de una rama en el tronco. Y también aumenta la complejidad: no solo necesitaría mantener el tronco actualizado, sino que también tendría que hacer lo mismo para mi rama.
66
@Andrew acumulando cambios en la máquina local es lo primero que debe eliminar, pase lo que pase. Otros problemas que mencionas también son reales, pero este es el primero en resolver
mosquito el
66
No entiendo realmente cómo pueden estar empujando los cambios si no han actualizado a nivel local, y por qué se está empujando rompen edifica en absoluto TBH
Inútil

Respuestas:

54

Para empezar, este comentario:

... tener una rama implica una complejidad extra y, por lo tanto, un trabajo extra ...

Es totalmente falso. A menudo lo escucho de personas que no están acostumbradas a ramificarse, pero aún así está mal.

Si tiene muchos desarrolladores acumulando cambios localmente, sus cambios locales constituyen una rama de facto del repositorio principal.

Cuando finalmente empujan, esta es una fusión de facto .

El hecho de que sus ramas y fusiones estén implícitas no elimina la complejidad adicional que le preocupa, solo lo oculta. La verdad es que hacer explícito este proceso podría ayudarlo (plural = todo el equipo) a aprender a administrarlo.


Ahora tu dices

nadie puede registrarse mientras que la construcción es roja

pero en este caso la compilación nunca se puede arreglar, por lo que no puede ser del todo precisa.

En general, si es razonable construir localmente (es decir, la construcción no es demasiado grande o lenta), los desarrolladores deberían hacerlo antes de continuar.

Supongo que este no es el caso, porque en primer lugar no impulsarían construcciones rotas, pero sería genial si pudieras aclarar este punto.

En general la respuesta a

cómo mantenerse eficiente cuando una construcción casi siempre se rompe

es: deja de romper la compilación .

Inútil
fuente
23
+9000 para "Deja de romper la compilación". Seriamente. El punto completo de la integración continua es dejar de romper la compilación y, si está rota, arreglarla lo más rápido y lo más cerca posible de la ruptura.
Patrick Hughes el
@ Inútil, me gusta su respuesta general, pero creo que debería haber corregido mi pregunta. Personalmente, no rompo la construcción y, al mismo tiempo, no quiero hacer olas que empujen mucho a otros para que puedan dejar de romper la construcción. Me gusta saber: ¿hay algo que pueda hacer MISMO MISMO para ser más productivo MISMO MISMO? Quisiera su opinión sobre esto. Aclamaciones.
66
Bueno, puede trabajar en su propia rama y ser selectivo acerca de qué cambios aguas arriba se fusionan en esa rama (es decir, tal vez solo cuando la construcción sea verde). Pero, esto realmente está reduciendo la interacción con el resto del equipo, cuando sería mejor en general arreglar el equipo para que pueda interactuar sanamente.
Inútil
14

desarrolladores ... acumulan sus cambios localmente ... Puedes ver el círculo vicioso.

Es vicioso de hecho. Acumular cambios a nivel local es una gran bandera roja que indica que algo está muy podrido en el proceso de desarrollo. Es una especie de basura todo el propósito de tener un sistema de control de versiones .

Mientras desee mantenerse alejado de cambiar el proceso o el comportamiento de otras personas, la solución más natural sería establecer su propia sucursal y usarla para "acumular" sus cambios (para integrarse aún más con la sucursal del equipo cuando obtenga un oportunidad).

En realidad, si hay más personas como usted, incluso puede colaborar y establecer una rama de desarrollo compartida para intercambiar libremente sus actualizaciones sin interferir con ideas de gestión incompetentes. La ramificación permite muchas formas diferentes de simplificar el trabajo en equipo.

  • Nota al margen, cada vez que el gerente hace o dice algo que lo obliga a evitar las confirmaciones, a mantener el código localmente, traduzca sus palabras en negrita y claro "Soy incompetente" .

tenga en cuenta que soy un desarrollador, no un gerente, y no puedo cambiar mucho el proceso o el comportamiento de otras personas ...

En aras de la precisión, en realidad puede , estos son asuntos de influencia y habilidades de comunicación y uno realmente no necesita estar en una posición de poder para cambiar las cosas a su gusto (busque en la web algo como "manejar" si usted Estoy interesado en más detalles).

Sin embargo, es bastante engorroso y requiere mucho esfuerzo, y puedo entender perfectamente si uno simplemente prefiere concentrarse en la codificación, con poca participación en la política, por lo que si no quiere (aunque en teoría sí puede ), es comprensible. :)

mosquito
fuente
7

Soy sensible a la idea de que te sientes impotente para cambiar el entorno, pero creo que esta situación es un serio desafío para tu profesionalismo como programador.

¿Qué pasaría si un cirujano almacenara escalpelos sucios con los limpios? ¿Qué pasaría si un plomero no probara las tuberías que instaló? ¿Qué pasaría si un violinista tocara siempre desafinado con la orquesta?

¿Por qué los programadores deberían estar exentos del trabajo en equipo y la cortesía común? Como miembro de ese equipo, usted comparte la responsabilidad del resultado. Es irresponsable ignorar al equipo, ya que sabotea sus propios esfuerzos.

Tengo curiosidad de dónde viene la regla de que "a nadie se le permite registrarse mientras que la construcción es roja". Es una buena regla si eso se centra en arreglar la compilación. Intentaría liderar con el ejemplo y ayudar a arreglar la construcción cada vez que se rompa. Seamos realistas, de todos modos no vas a hacer nada más. Si esto te molesta, entonces sugeriría expresar esas preocupaciones. La voz de alguien que trata activamente de mejorar una situación tiene más influencia que el tipo que se queja en la esquina.

Steve Jackson
fuente
5

Creo que mientras piense que es "solo un desarrollador" y, por lo tanto, no puede cambiar las cosas, sufrirá este problema.

Lo que debe hacer es revertir cada confirmación del repositorio cada vez que alguien interrumpe la compilación y luego decirle a ese tipo que acaba de romper la compilación y que debe detenerse. También debe explicar esta situación al gerente y decirle que la productividad de su equipo está sufriendo debido a este problema.

Debe hacer todo lo posible para cambiar el proceso mejor y más bien pedir disculpas más tarde en lugar de pedir permiso.

Creo que usted y su equipo se encuentran en una situación en la que es necesario cambiar el proceso y no pueden trabajar de manera eficiente con ese modelo roto. También creo que es su responsabilidad hacer algo al respecto cuando lo haya reconocido. Si nadie más va a hacer nada sobre el problema, ¡usted es quien debe hacerlo!

hequ
fuente
-2 y nadie quiere compartir por qué ... je je.
hequ
1
No puedes hacer una tortilla sin romper algunos huevos.
William Payne
2

Puedo relacionarme con tu situación, me enfrenté a una situación similar con mi proyecto más reciente en el trabajo. Terminamos implementando una especie de sistema de "papa caliente" en el que el desarrollador que recientemente rompió la compilación tuvo que cuidarlo / niñera / monitorearlo hasta que se solucionó Y pasó todas nuestras pruebas de verificación.

Esto fue exitoso porque las pruebas de compilación y verificación rutinariamente tomaron ~ 4 horas, por lo que romper la compilación significaba que perdía medio día haciendo un trabajo real. No hace falta decir que esto dio como resultado que los desarrolladores usaran ramas de manera más eficiente antes de fusionarlas en el tronco. Para la mayoría de los desarrolladores, la mentalidad anterior era "Dejaré que el sistema de compilación de CI me notifique si mi código está roto".

Sam Miller
fuente
1

Un simple cambio en el sistema CI lo haría: cualquier cambio que rompa la compilación se revierte automáticamente. Aún mejor, deje que el repositorio de CI se convierta en un área de preparación, donde los cambios solo se envían al repositorio autorizado cuando la compilación es verde. Herramientas como Gerrit pueden ayudar aquí.

William Payne
fuente
3
Pero para hacer esta tarea imposible "... tenga en cuenta que soy un desarrollador, no un gerente, y no puedo cambiar el proceso ..."
SChepurin
@SChepuritu proceso es ineficiente, debes cambiar el proceso, punto. Como desarrollador, es posible que no pueda aprobar el cambio, pero siempre puede trabajar para mejorar el proceso.
oefe
1

Otras dos cosas podrían ayudar aquí:

  • ¿Puede su equipo probar el humo de una construcción de CI localmente? Si verifica que no rompe la compilación, o al menos no la rompe de manera común sin tener que comprometerse y desencadenar la gestión y la ira del equipo.
  • Hay muchas formas de definir compilaciones rotas dependiendo de cómo se construya el CI. Esto incluye la definición de roto: en un desarrollo intenso, no consideramos que las pruebas fallidas sean un descanso, sino más bien otro objetivo por el que trabajar.

Pero realmente deberías mirar las ramas.

Wyatt Barnett
fuente