¿Es una buena práctica comprometer / registrar el código todos los días?

63

He estado leyendo la nota de Martin Fowler sobre Integración continua y él enumera como imprescindible "Todos se comprometen con la línea principal todos los días".

No me gusta confirmar código a menos que la sección en la que estoy trabajando esté completa y que en la práctica confirme mi código cada tres días: un día para investigar / reproducir la tarea y hacer algunos cambios preliminares, un segundo día para completar los cambios y un tercer día para escribir las pruebas y limpiarlas ^ para enviarlas. No me sentiría cómodo enviando el código antes.

Ahora, saco los cambios del repositorio y los integro localmente generalmente dos veces al día, pero no me comprometo tan a menudo a menos que pueda hacer un trabajo más pequeño.

Pregunta: ¿comprometerme todos los días es una práctica tan buena que debería cambiar mi flujo de trabajo para acomodarlo, o no es tan aconsejable?

Editar: Supongo que debería haber aclarado que quise decir "comprometerse" en el sentido de CVS (también conocido como "push"), ya que eso es probablemente lo que Fowler habría querido decir en 2006 cuando escribió esto.

^ El orden es más arbitrario y depende de la tarea, mi punto era ilustrar el lapso de tiempo y las actividades, no la secuencia exacta.

version-control

— Trineo
fuente

20

Puede confirmar su código si se compila y realiza alguna lógica útil. Es mejor comprometer el código en ciclos cortos si está trabajando en un entorno de equipo.

— EL Yusubov

44

¿Martin Fowler está asumiendo un VCS que no se distribuye?

— user16764

44

Tenga en cuenta la fecha en ese artículo: 1 de mayo de 2006. Git y Mercurial ni siquiera se iniciaron hasta abril de 2005, y mi impresión es que realmente comenzaron a ganar terreno alrededor de 2008. No puedo encontrar ningún artículo en el sitio de Fowler que haga referencia a cualquiera de ellos antes de 2009. Por lo tanto, este artículo de 2006 supone claramente un sistema de control de fuente centralizado como SVN. El consejo no es aplicable a los equipos que utilizan un DVCS.

— Kyralessa

2

@ Kyralessa: El artículo incluso afirma que "Subversion es el moderno [sistema de control de versiones]".

— che

44

Primero el código y luego las pruebas?

43

No estoy de acuerdo con esta regla y estoy de acuerdo con lo que dijo Mason Wheeler . Me gustaría agregar algunas ideas.

Intento comprometerme cada vez que tengo un cambio significativo que comprometer: esto puede ser varias veces al día si reparo varios errores pequeños, o una vez a la semana si estoy trabajando en un software más grande que no puede ser usado por el resto de el código de manera significativa hasta que alcance un estado consistente.

Además, interpreto el compromiso como la publicación de una revisión significativa que aporta una nueva funcionalidad a la base del código. Creo que uno debería tratar de limpiar el código antes de comprometerse para que otros desarrolladores puedan comprender el significado y el propósito del cambio cuando miran el historial de revisiones. Cuantos menos cambios vean otros desarrolladores en el historial, mejor: cuando miro el historial de revisiones quiero ver incrementos que agreguen alguna funcionalidad significativa; No estoy interesado en cada pequeña idea que cada desarrollador tenía y quería probar antes de llegar a la solución.

Además, no creo que sea una buena idea usar el servidor SVN (o cualquier sistema de control de versiones) como un recurso de respaldo al que se compromete la instantánea actual del código (siempre que se compile): puede usar una memoria USB o una unidad USB externa o un disco de red para reflejar su código actual para que no se pierda si su computadora se descompone. El control de revisión y la copia de seguridad de datos son dos cosas diferentes. Publicar una revisión no es lo mismo que guardar una instantánea de su código.

Finalmente, creo que no debería ser un problema comprometerse de vez en cuando (es decir, solo cuando uno está realmente satisfecho con el estado actual del código) y evitar conflictos de fusión no es una buena justificación para comprometerse (demasiado) a menudo. Muchos conflictos de fusión ocurren cuando diferentes personas trabajan en los mismos archivos al mismo tiempo, lo cual es una mala práctica (ver, por ejemplo, este artículo , punto 7). Los conflictos de fusión deben reducirse dividiendo un proyecto en módulos con interfaces claras y la menor cantidad de dependencias posible, y coordinando el trabajo de los desarrolladores para que el código en el que trabajan se superponga lo menos posible.

Solo mis 2 centavos.

EDITAR

Otra razón contra las confirmaciones prematuras que se me ocurrió es que no se puede probar una versión (muy) defectuosa. Si se está comprometiendo en el tronco y su equipo de prueba está probando todos los días, es posible que no tengan una versión comprobable durante unas horas (o por un día). Incluso si no intenta corregir el error y simplemente revierte los cambios, una reconstrucción puede demorar un par de horas. Con, por ejemplo, cinco probadores trabajando en su equipo, ha perdido 5 x 2 = 10 horas del tiempo del equipo debido a la inactividad. Me sucedió una vez, así que realmente trato de evitar los commits prematuros en nombre del commit lo antes posible .

— Giorgio
fuente

23

Un 'commit' no es un 'publicar'. 'Comprometer' significa 'instantánea'; 'publicar' se llama 'empujar' en scm-lingo. Por supuesto, SVN simplemente fusiona ambos conceptos en uno, haciendo que muchos flujos de trabajo sensibles sean imposibles, pero eso es una limitación de la herramienta, no de los flujos de trabajo de control de origen en general.

— tdammers

3

Revision control and data backup are two different thingsSí, definitivamente me siento así.

— Trineo

1

@tdammers: quise publicar de manera informal: mientras el código esté en mi computadora, son mis cambios privados al código común. Tan pronto como lo confirmo, se publica, conocido por el resto del equipo y parte de la historia oficial del proyecto.

— Giorgio

1

En ese caso, 'commit' es probablemente la palabra incorrecta. Muchos SCM permiten compromisos locales, y compartir su código con el resto del equipo es una acción separada, generalmente llamada 'push'. Nuevamente, SVN agrupa los dos conceptos, pero eso es una limitación de la herramienta, y si se interpone en su flujo de trabajo, considere cambiar a un SCM diferente.

— tdammers

@tdammers: Tener una distinción clara entre el compromiso local y la publicación sería un paso adelante. Sin embargo, en SVN puedo usar una rama separada para eso. Pero, una vez más, me pregunto por qué querría hacer un seguimiento de una revisión que no tiene mucho sentido para mí. No estoy convencido de que quiera una nueva revisión (incluso una privada) solo porque son las 5 en punto y me voy a casa. Prefiero tener una copia de seguridad en su lugar.

— Giorgio

107

Cometo código varias veces al día . Cada vez que llego a un punto donde el código está lo suficientemente completo como para compilar y no rompe otras cosas, entra.

Debe considerar dividir su trabajo para poder registrarse con seguridad algunas veces al día.

Las razones para esto son dos:

Cualquier trabajo que no esté registrado puede perderse; su computadora puede tener una falla catastrófica. En este caso, cuanto más espere, más trabajo perderá.
Cuanto más trabajo realice sin registrarse, más código necesitarán integrar otros cuando finalmente decida que se hornea. Esto introduce más posibilidades de conflictos y problemas de fusión.

— Oded
fuente

2

Si tiene un problema grave con conflictos y problemas de fusión, significa que su gerente de proyecto no está haciendo su trabajo. Múltiples casos que involucran una funcionalidad similar deberían ir al mismo desarrollador, precisamente para que no tenga dos o más codificadores pisoteando el trabajo del otro.

— Mason Wheeler

14

@MasonWheeler: después de 3 días de trabajo que no se ha comprometido, existe una gran posibilidad de que uno haya tocado el código que otros tienen al mismo tiempo. Si tiene un grupo de programadores haciendo esto, el mejor gerente de proyecto no puede evitar conflictos.

— Oded

3

@Oded: Quizás. Supongo que mi respuesta está coloreada por mi experiencia en una base de código lo suficientemente grande como para que nuestros desarrolladores (una docena de codificadores en el equipo) tiendan a tener responsabilidades que no se superponen. No estoy seguro de cuán diferente sería en proyectos más pequeños.

— Mason Wheeler

3

@ArtB: ¿Qué sucede si hay alguien como usted que solo se registra cada 3 días? O una vez a la semana? Estás confiando en que otros hagan lo correcto.

— Oded

3

Cuando leí la pregunta, mi respuesta fue "¿es como preguntar si es una buena idea bañarse todas las semanas"?

— Andrew Grimm

39

Adherirse a cualquier metodología o práctica sin comprender las razones detrás de esto nunca es una buena idea. De ahí viene la programación de culto a la carga.

Por lo tanto, "debería comprometerme todos los días porque Martin Fowler lo dijo" es una estupidez. Y a veces tampoco es práctico. Si está trabajando en una nueva característica complicada, es posible que no llegue a un punto en el que valga la pena registrarse hasta que ya haya trabajado en ella durante unos días.

Esto no significa que deba asegurarse de que todo esté perfecto antes de registrarlo. Esa es una buena manera de perder el trabajo si algo sale mal. Lo correcto es desarrollar y utilizar el buen juicio al respecto. Las reglas generales solo pueden ayudarte mucho.

— Mason Wheeler
fuente

1

Entonces, si se trata de integración / desarrollo de características complejas, sigue siendo una gran pérdida no comprometerlo, tal vez no en el tronco, pero al menos en una rama para esta característica, ¡para eso están las ramas!

— Vincent B.

2

¿Qué quieres decir con "vale la pena registrarse"? Si no rompe el código de otra persona, ¿por qué no lo registras?

— Kirk Broadhurst el

2

"¿A qué te refieres con 'vale la pena registrarse'? Si no rompe el código de otra persona, ¿por qué no lo registras?": Porque no quiero guardar copias antiguas del código solo porque existían punto en el tiempo. También quiero conservar una copia antigua del código si contiene información útil que podría querer recuperar en el futuro. De lo contrario, solo estoy produciendo ruido inútil en el historial de revisiones.

— Giorgio

3

+1. Una vez trabajé en un equipo donde teníamos que registrar el código en las VCS todos los días, incluso si el código era un pico o una investigación inútil. Resultó ineficiente y derrochador, particularmente porque requería un mantenimiento periódico para limpiar las vcs. Se debió a la combinación de paranoia por el riesgo potencial de perder un poco de tiempo para rehacer algo, y porque el gerente había leído en un libro que debes comprometerte todos los días. Un ejemplo extremo quizás, pero en serio, si no tiene el criterio de saber si "vale la pena" registrar algo, probablemente no esté bien preparado para el trabajo.

— S.Robins

14

Oded dio dos razones importantes para confirmar el código con la mayor frecuencia posible. Agregaré algunos más:

Mientras trabaja en su código, otros podrían necesitar algunas funciones en ese código. No deberían esperar 6 días para obtenerlo. En este caso, mis colegas generalmente crean un prototipo en mi código, lo confirman, agrego el cuerpo y lo confirmo nuevamente. Y esto generalmente se hace en unas pocas horas.
El código 'común' es para que todos vean cada cambio lo antes posible. Si el código en el que está trabajando está totalmente separado del trabajo de los demás y no los hará esperar, entonces se recomienda crear una rama para que trabaje y luego, si todo tiene éxito, combínelo para La línea principal.

— superM
fuente

1

¿Por qué esta respuesta con (IMO) es la única respuesta correcta y precisa (punto 2) con una calificación tan baja? ¡Por supuesto que ese es el punto de una rama! @Mason Wheeler: ¿Entonces disfrutas codificar varios días sin procesar una sola vez? Entonces, ¿por qué usar un sistema de control de versiones?

— Vincent B.

2

Esta es la respuesta correcta. Si su tarea es muchos días de trabajo antes de que sea utilizable, bifurque. De lo contrario, se compromete cada vez que funciona para garantizar que los miembros del equipo tengan la última versión, pueden probar que funciona e identifican las características agregadas / faltantes lo antes posible.

— Kirk Broadhurst

"¿Así que disfrutas codificar varios días sin procesar una sola vez? ¿Entonces por qué usar un sistema de control de versiones?": Porque eventualmente quieres comprometer una revisión, a pesar de que no estás obligado a comprometerte ciegamente todos los días. Más bien, depende de usted decidir si se compromete varias veces al día o si trabaja tres días seguidos sin comprometerse. Realmente no veo el punto de comprometer alguna característica inacabada que nadie puede usar: solo haga una copia de seguridad, al día siguiente puede terminarla y comprometerla.

— Giorgio

8

Creo firmemente en cometer todos los cambios lógicos que vale la pena mantener. Comprometerse con frecuencia, y si no vale la pena mantener el código, vuelva a ponerlo en un estado limpio. Cuanto más espere para enviar / publicar su código, más difícil será implementarlo y más problemas tendrá. También recibirá comentarios sobre sus contribuciones mucho más rápido:

¿Rompen la construcción?
¿Estás duplicando los esfuerzos de otro miembro del equipo?
estas haciendo algo incorrecto?
¿O la gente está esperando cosas tuyas?

Los pequeños cambios son mucho más fáciles de administrar.

Además, vale la pena señalar la diferencia entre los diferentes sistemas de control de versiones. Algunos, como Git (distribuido), le permitirán confirmar y controlar su historial completo localmente, solo presionando cuando esté listo para publicar. Otros, como SVN (centralizado), combinarán los dos pasos haciendo que las pequeñas confirmaciones sean muy ineficientes.

No olvide que sus confirmaciones son esencialmente documentación de cambios. Cuando las cosas salgan mal, te alegrará tener más historia que la suficiente. Un solo compromiso por un trabajo de una semana me parece inútil. Acabo de leer cada línea de código modificada en lugar del resumen de cada fragmento lógico.

— Adrian Schneider
fuente

5

Creo que la mayoría de las respuestas aquí pierden uno de los puntos principales en la declaración de Martin Fowlers. Esto está relacionado con la integración continua . El código que no se registra (se envía / publica / combina) en la línea principal no se prueba.

Esto no debe leerse como un estímulo para comprometer cualquier código que tenga en su máquina local cada vez que sea hora de salir de la oficina. Como señalaron varios otros aquí, eso sería malo, rompería la construcción y causaría una línea principal inestable.

Sin embargo, es alentador intentar realizar los cambios en pequeños pasos que se pueden registrar en la línea principal sin causar problemas. Esto fomenta la evolución del código en lugar de desgarrarlo todo y reescribirlo.

Ahora, ¿qué tiene de bueno esta forma de trabajar?

No cometer grandes fragmentos de código o cambios revolucionarios reduce la posibilidad de romper la compilación.
Si su confirmación rompe la compilación, es bastante trivial identificar cuáles son los problemas, revertirlo y luego confirmar una versión fija rápidamente.
Al asegurarse de que todas las pruebas se ejecutan en cada pequeño cambio en el código, se asegura de no introducir errores sutiles o regresiones que pueden provenir de que el código crezca fuera del esquema de integración continua.

Por supuesto, no todos los cambios se prestan a este enfoque. Como otros señalaron, ninguna regla es absoluta. Sin embargo, para los cambios que se espera que permanezcan fuera de la línea principal durante mucho tiempo, configure una línea principal alternativa con su propio esquema de integración continua y siga el mismo enfoque. Con los VCS distribuidos de hoy es algo bastante fácil de hacer.

— harald
fuente

+1: "Por supuesto, no todos los cambios se prestan a este enfoque". Creo que este es el punto. El consejo de Fowler me parece correcto, pero uno debe juzgar de un caso a otro. En cambio, este consejo a menudo se generaliza a una regla absoluta y se sigue sin ninguna consideración adicional.

— Giorgio

@ Jorge, estoy absolutamente de acuerdo contigo en eso. Ningún consejo debe tomarse como reglas absolutas, sin importar quién lo respalde.

— harald

Algunas ideas más sobre esto. "El código que no se registra (insertado / publicado / fusionado) en la línea principal no se prueba": estoy de acuerdo en que este es un buen principio y que uno no debe esperar semanas antes de registrarse y hacer que se pruebe su código. Sin embargo, la aplicación ciega de este principio puede conducir a una aplicación que no se puede probar (lo he visto en vivo: todo el equipo de prueba permanece inactivo durante días y no puede probar nada hasta que el código vuelva a un estado utilizable). Tal vez lo que escribieron otros usuarios es aplicable a algunas situaciones, pero no lo es en general.

— Giorgio

1

Registrar un código inestable nunca está bien. Una confirmación que rompa el elemento de configuración debe revertirse. Si comete pequeños cambios incrementales a menudo, hay menos posibilidades de introducir tal ruptura que si tiene un gran cambio que no se ha probado durante mucho tiempo. También puede ser más fácil revertir si se rompe la construcción. Pero como dices, a veces no hay forma de un cambio disruptivo. Luego, por supuesto, púlselo lo mejor que pueda y pruebe a fondo antes de cometerlo. El punto no es seguir las reglas, sino entender de dónde viene el consejo.

— harald

3

Argumentos para registrarse todos los días:

El código se almacena y se realiza una copia de seguridad contra la falla del disco duro
La actividad se puede registrar en notas de confirmación ( ¿qué hice el jueves ...? )
La integración con la base de código existente ocurre antes y en fragmentos más pequeños, con la esperanza de identificar conflictos o fusionar problemas antes
Tu equipo tiene visibilidad de lo que has estado trabajando
Sus colegas pueden trabajar contra sus interfaces antes, dándoles más tiempo para integrarse con su 'gran código complejo'
Su código será probado en el mundo real antes, o al menos estará expuesto a más uso del que le dará, lo que conducirá a una identificación más temprana de errores u omisiones.

Argumentos en contra de registrarse todos los días:

No necesito o no quiero
Todavía no he "limpiado" mi código, es un desastre
No tengo tiempo

No creo que haya una buena razón para registrarse menos de un día, aparte de la pereza o la desorganización. Nada peor que ver que el código que se ejecuta en el entorno de desarrollo no coincide con el código en la rama de desarrollo porque alguien "aún no ha terminado" y, por lo tanto, no se ha registrado.

Me encantaría estar equivocado en esto, así que hágame saber cualquier argumento legítimo contra el check-in diario.

— Kirk Broadhurst
fuente

"No creo que haya una buena razón para registrarse menos de un día, aparte de la pereza o la desorganización": creo lo contrario por exactamente la misma razón. Puedo tomarme el tiempo de mirar el estado actual del código y decidir si contiene información relevante que valga la pena recordar, o si soy vago y desorganizado, simplemente puedo verificarlo (y producir revisiones adicionales con poca información). contenido) siempre que se compile.

— Giorgio

1

Entiendo su punto de que uno no debe ser perezoso y limpiar su código todos los días para que pueda registrarse. Por otro lado, cuando se trabaja en algún código complejo, esto es difícil de lograr porque la limpieza puede tomar varias horas , y no puede pasar varias horas todos los días solo para limpiar su código.

— Giorgio

@Giorgio ¿Entonces pasaste varios días limpiando tu código? He dado algunas buenas razones para registrarse diariamente. ¿Su razón es que tendrá que limpiar su código? Simplemente escriba un código más limpio hacia arriba.

— Kirk Broadhurst

Esto no siempre es posible, por ejemplo, si estoy desarrollando desde cero algún código complejo (> 4000 LOC) que necesita mucha experimentación para hacerlo bien. Es muy posible que al final del día el código esté un poco desordenado y no quiera arreglarlo hasta que llegue a un estado consistente, que es un par de días después. Desafortunadamente, no soy tan inteligente como para que se forme un código perfecto en mi mente y siempre puedo tenerlo todo escrito en unas pocas horas (es decir, al final de un día). Tuve tal experiencia últimamente y el ciclo de desarrollo típico (de un estado constante al siguiente) fue de 2, 3 días.

— Giorgio

@Giorgio, ¿no tiene una rama de desarrollo en la que se está registrando? El código debe registrarse para que otras personas puedan revisarlo y probarlo también.

— Kirk Broadhurst

2

Si quiere decir "comprometerse" como "fusionarse en la línea principal", definitivamente no debería hacerlo todos los días en un proyecto de software que se lanza a los clientes. Debería fusionar los cambios que se realizan y prueban, para que la línea principal siempre funcione y se pueda liberar, y no en un estado roto con características a medio terminar.

Sin embargo, el lujo de trabajar con el control de versión distribuido de hoy en día es que ambos pueden mantener la línea principal estable y, al mismo tiempo, hacer lo mismo git/hg/whatever commitcada vez que sienten que desean preservar el estado de las cosas. Hago esto una vez cada pocas horas y definitivamente al final de cada día.

Con DVCS, puede publicar su trabajo, colaborar en él con otros miembros de su equipo y mantenerlo actualizado con los cambios en la rama principal. Puede hacer todo esto sin contaminar la estabilidad del código del que dependen sus clientes u otros equipos.

En tiempos en que Subversion era la última tecnología y no había forma de bifurcar y fusionar ramas de características sin un dolor extremo, tener una línea principal donde varias características diferentes se encontraban en construcción simultánea podría haber sido el mejor enfoque. Pero esta superioridad no se extiende más allá de 2010.

— che
fuente

2

En Team Foundation Server puede 'Shelve', que no es lo mismo que registrarse, pero solo hace una copia de seguridad de su código para que si su máquina muere no haya perdido los cambios.

También he visto casas de software que tienen una 'línea de desarrollador' y una 'línea principal'. Los desarrolladores son libres de registrarse en la línea del desarrollador cuando lo consideren conveniente y solo el líder del equipo tiene acceso a la línea principal, por lo que son responsables de copiar el código del desarrollador al principal cuando esté listo para la producción.

— Matt Wilko
fuente