Construcciones continuas y Agile vs commit a menudo

Solo estoy haciendo un entrenamiento formal en Agile en este momento y una de las preguntas que tengo es acerca del valor de las comstackciones continuas frente al valor de comprometerse con el sistema de control de versiones a menudo.

Mi comprensión con el control de versiones es que es mejor comprometerse a menudo, porque entonces usted tiene historial y la capacidad de volver a los cambios previos de una manera detallada.

Mi comprensión con la creación ágil y continua es que está allí para presionar a los desarrolladores para que siempre tengan código de trabajo. Que romper el tree fuente es algo tabú que hacer.

Ahora estoy de acuerdo con estos dos sentimientos, pero parece ser que a veces estos pueden estar trabajando uno contra el otro. Es posible que se encuentre en medio de un cambio de código importante y desee confirmar el código para asegurarse de que tiene historial, pero esto romperá el tree fuente.

¿Alguien tiene alguna idea sobre esto?

¿Qué podría ser less ágil que un tabú sobre algo que está saliendo mal? Yo diría que el tabú es dejar la construcción rota en lugar de romper la construcción. La rotura ocasional de la estructura está bien. Esta es exactamente la razón por la que está ejecutando comstackciones y testings continuas. La construcción / testing de CI identifica cuándo se rompe la construcción, e idealmente quién la rompió. Esto asegura que se solucione rápidamente. Si esto sucede ocasionalmente, estás bien. Si ocurre veinte veces al día, el equipo probablemente esté en problemas.

El tabú es interferir con otras personas haciendo su trabajo. Cuando se rompe la compilation, reciben un correo electrónico que dice: "nuestra twig de origen está reventada". No podrán integrar los cambios de otras personas o sus cambios con la línea principal hasta que obtengan el correo electrónico claro.

El verdadero desafío para trabajar en este tipo de entornos de continuous integration es: 1) Mantener los equipos bastante pequeños. En general, empezamos a ver problemas después de que unos 25 desarrolladores forman parte del equipo. Las cosas comienzan a ponerse frágiles. El uso de twigs, componentes o CI de etapas múltiples a nivel de equipo con transmisiones puede ayudar a los equipos más grandes a dividirse en equipos más pequeños.

2) Elegir pequeñas unidades de trabajo. Por lo general, no debe haber un conflicto entre el control de las mejoras de forma regular y el no romper todo. Se deben hacer compromisos cuando se hacen pequeños cambios de trabajo. Es posible que la nueva característica aún no esté expuesta al usuario, pero si se realiza un cambio de API coherente que no interrumpe las testings, regístrese.

3) Comstackciones rápidas y precisas. Hay muchas condiciones de carrera que el equipo tiende a ganar más seguido cuando la construcción se hace más rápida. Además, las comstackciones reproducibles asegurarán que la compilation que hace el desarrollador en su propia máquina (que tuvo time de hacer porque era rápida) pnetworkingiga con precisión razonable el éxito en la confirmación.

Las twigs / tags resuelven esto, en la mayoría de los sistemas de control de fuente.

Le permiten marcar o simplemente 'ramificar' (juego de palabras intencionado) un segmento / revisión de código y tenerlo como la 'versión estable'. A continuación, puede realizar cambios en el tronco principal, una twig de "parche" u otros enfoques.

Los dos conceptos trabajan juntos.

En realidad, una filosofía Ágil común (con la que he estado muy feliz) es la siguiente: "Si no puedes comprometerte antes de volver a casa, revéncelo".

Al principio esto suena brutal, así que generalmente copio mi tree fuente localmente o lo ramifico, y luego vuelvo a donde comencé. Al día siguiente, comienzo el trabajo de nuevo. Suele ser MUY RÁPIDO, mejoro sobre lo que hice el día anterior y rara vez o nunca miro la copy (Bueno, a veces retiro algunas classs que tenía "Completadas" y me sentía seguro de ellas y las volvía a integrar .

Casi nunca tengo la necesidad de pasar más de unas pocas horas sin registrarme. Trato de usar refactores (SIEMPRE son muy cortos e inofensivos o no son refactores) y agrego el código de tal forma que las cosas no se rompen . Esto podría implicar la adición de un código probado (un nuevo método u object) y verificarlo antes de vincular el rest del código.

En general, las testings de su unidad SIEMPRE deben ejecutarse. Tiendo a hacer testings tan a menudo como unas pocas veces por minuto y raramente más de una vez cada diez minutos.

Seguir los pequeños pasos puede llevar un poco más de time, pero evitará las sesiones de reescritura de códigos de 3-4 días en las que no se pueden realizar testings ni registrarse, ¡esas pueden ser brutales y una GRAN pérdida de time!

Agregaré otra respuesta, porque para mí parece que algunos de los puntos más importantes no se han mencionado.

Mi comprensión con el control de versiones es que es mejor comprometerse a menudo, porque entonces usted tiene historial y la capacidad de volver a los cambios previos de una manera detallada.

Estoy absolutamente de acuerdo con esto

Mi comprensión con la creación ágil y continua es que está allí para presionar a los desarrolladores para que siempre tengan código de trabajo.

No está ahí para presionar a los desarrolladores; prefiero describir la continuous integration como una networking de security amigable que te ayuda a detectar problemas tan pronto como los cometes, cuando arreglarlos suele ser fácil. (Consulte el artículo seminal de Martin Fowler para get más beneficios de CI.) Es importante tener siempre código de trabajo, y es ahí donde entran las twigs de control de versiones, como se señaló sedoso . Pero a diferencia del escenario tradicional que describe (y de lo que Fowler habla: "Todo el mundo se compromete con la línea principal todos los días"), recomendaría lo contrario: mantenga su tronco principal estable, preferiblemente siempre en forma liberable, y haga todo el desarrollo en twigs temporales de trabajo.

He conectado el enfoque de tronco estable en SO aquí y aquí ; ver esas publicaciones para alguna justificación y experiencias de este model. Además, recomiendo encarecidamente este artículo que influyó mucho en mi forma de pensar: Control de versiones para múltiples equipos ágiles de Henrik Kniberg.

Romper la compilation en una twig de desarrollo está lejos de ser un tabú, aunque aún debes tratar de mantener todo comstackdo y pasar todas las testings. Romper la construcción del maletero , en este escenario, es algo más serio, pero aún así no lo llamaría un tabú: estas cosas pasan de vez en cuando, y en lugar de encontrar a alguien a quien culpar, es infinitamente más importante para el equipo simplemente corrígelo (y sé feliz de que el problema haya sido encontrado ahora , en lugar de mucho más tarde, tal vez por parte de un cliente).

Use Git para ramificar, fusionar y reescalonar fácilmente.

Silky es perfecto, la ramificación / labeldo resuelve esto (svn plug para esta funcionalidad).

Soy un gran admirador de la dedicación a menudo, y personalmente encuentro que es más fácil evitar que se rompa la compilation, porque estoy probando cada unidad una cantidad menor de código cada vez.

TDD te permite tener ambos

Una solución a esta aparente paradoja es la práctica ágil de desarrollo de software de Test Driven Design (TDD). Si se practica bien, es fácil codificar con frecuencia y tener comstackciones continuas que rara vez se rompen con el código que no funciona.

Primero obtenga el código más reciente del repository y ejecute todas las testings. (Si no todos pasan, anule la última persona para comprometerse.) Escriba una testing para una funcionalidad pequeña ( antes de haber implementado la funcionalidad), luego implemente la funcionalidad y vuelva a ejecutar todas las testings. Actualice su código desde el sistema de control de versiones en caso de que algo haya cambiado mientras estaba trabajando, vuelva a ejecutar todas las testings y, si todas pasan, puede hacerlo en ese momento. Eso es "rojo-verde" del concepto ágil Red-Green-Refactor. Después de eso, haga cualquier refactorización necesaria y vuelva a ejecutar todas las testings. Si aún eres verde, podrías volver a cometer en ese momento.

La mayoría de los equipos ágiles tienen un server de continuous integration que se ejecuta en un horario regular (a menudo por hora o más) y tiene un indicador visible grande (como un semáforo) que muestra si la compilation más reciente ha pasado, ha fallado o está en process.

Tener una database de control de versión local si tiene que

Si no puede evitar tener "cambios de código importantes", use su propio repository de control de versiones local, usando algo como git como sugiere Gordon Potter, y comprométase cuando haya terminado con su cambio. Puede hacerlo incluso si su equipo usa algún otro producto de control de versiones.

Para un cambio significativo o grande que pueda romper piezas dependientes de código, una twig sería apropiada. En el punto en el que desee integrar este cambio y verificar en el enlace troncal o en cualquier twig de integración a la que lo promocionará, habiendo solucionado los problemas y haciendo que todas las testings funcionen, es esencial.
No creo que las dos cosas funcionen cara a cara. El uso de twigs o control de fuente distribuida lo haría más fácil de administrar.

Tendrá que examinar qué tipo de historial tiene sentido durante una fusión. Digamos que tienes un progtwig que usa muchos modules cargables, podría ser un núcleo … un server web, lo que sea.

Al escribir un module, usted realiza 200 commits, cuando se fusiona con el proyecto principal, probablemente solo desee un parche (aunque sea grande), quizás dos:

  • Introducir el module Foo
  • Actualizar Makefiles para build foo

Esta es una de las razones por las que Git se ha convertido en una presencia tan dominante en el mundo de DVCS.

La frecuencia de compromiso elegida realmente no tiene relación con el método de desarrollo de software que desee emplear. Puede comprometer 200 revisiones bien probadas, o una, siempre que las personas que extraen lo que empuja no ingieran revisiones o regresiones tóxicas en su código causadas por las suyas (a less que, por supuesto, su código expone un problema en las suyas).

A mí (personalmente) me gusta hacer pequeños commits, por las mismas razones que me diste. De hecho, generalmente es ideal si todos trabajan en una twig central. Sin embargo, si trabajas en algún sistema secundario durante 6 meses, realmente preferiría que me enviaras algunos parches grandes, en lugar de henetworkingar toda tu historia … siempre tienes tu historial en tu repository de trabajo, y probablemente solo sea interesante para tú 🙂

Si el cambio de código grande está en una twig separada, esto no rompe la construcción necesariamente. Al tener una twig sobre sí misma, los cambios se mantienen fuera del código hasta que se realice el cambio y luego todo se puede fusionar de nuevo en un tronco o línea de código principal. La key es que, aunque hay una construcción continua, no necesariamente includeá cosas que no están "hechas y hechas".

Me parece que Git resuelve este problema. Mantenga un repository local y comprométase temprano, comprométase con frecuencia y luego, cuando el código llegue a un hito no roto, salga al repository compartido principal. Si todo el equipo usa Git, entonces todo el historial del repository se puede mantener en el repository de todos los demás cuando hagan cambios. Y todo sin romper necesariamente la construcción.

Y con la re-baseización, ni siquiera tiene que exponer todo su historial de compromisos locales cuando saca hitos.