Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Desarrollo Software Universos Paralelos Ramas
- 1. Universos Paralelos en el Desarrollo del Software Patrones de branches and merging
- 2. Quiénes somos? Amalia Twitter: @amaliahern email: amalia@codicesoftware.com Manu Twitter: @mrcatacroquer email: mlucio@codicesoftware.com
- 4. Hoy hablamos de… • ¿Qué es un control de versiones? • Universos Paralelos: Ramas • Demuestra tus poderes con patrones
- 5. ¿Qué es un control de versiones?
- 6. Si crear ramas no te asusta, ¿por qué no haces más?
- 8. Ramas y Universos Paralelos
- 10. Rama por Release
- 11. Rama por Release
- 16. Rama por Tarea
- 17. Rama por Tarea
- 18. ¿Por qué crear Ramas?
- 19. Anti -patrones
- 20. Anti -patrones
- 21. Anti -patrones
- 22. Anti - patrones
- 23. Anti -patrones
Notas del editor
- GoalMostrar Plastic SCM desde los patrones de ramas y branches. Indicarcomotrabaja Plastic Hoy venimos a hablar de codigo, de control de versiones, y de comopuedestrabajar de maneramáseficiente con tucodigoempleandolasramas, porqueporsupuestotienestodotucodigobajoconrol.AudienceDesarrolladoresprincipalmenteHow to explain itPartiendo de unabreveintroduccionteorica de cadapatrón, mostrarejemplos de uso: como Plastic resuelve y trabaja con esospatronesfrente a otros DVCS.Additional material
- Hoy solo estamos dos de los componentes de todo el equipo de Plastic, en el que hay8 Developers1 CEO1 Techwriter1 Build master1 Testing masterDonde Manu y yo cumplimos el papel de:1 Support/multitask master1 Multitaskwoman
- ¿Qué es una rama?Cuando necesitas hacer por ejemplo el mantenimiento de un documento para dos clientes, de manera natural te sale hacer dos copias de ese documento y llevar lineas independientes de mantenimiento.Este es el concepto de rama, una línea de desarrollo que existe de manera independiente a otra, pero que comparten historia común.Una rama siempre comienza su vida como copia de algo, y se mueve hacia adelante, creando su propia historia.Dos preguntas:Si nunca has creado una rama, ?no crees que estás desaprovechando todo el potencial de tu control de versiones?Y si crear ramas no te asusta, por que no haces mas?Muchas veces el concepto de rama no se entiende bien, porque en realidad cuando revisas los sistemas de control de versiones no ves que los desarrolladores creen tantas ramas, a pesar que la creación de ramas como el versioneado forman el corazon de un sistema de control de versiones.
- Problemas…..Fácil de crearpasa a sercomplejidadinfinita. Aunque las ramas te ofrecen la seductora posibilidad de ser infinitas con poco riesgo, traen también consigo las menos deseable: complejidad infinita.En Marvel la complejidad nacia de cual era el pasado de SuperMan: tuvieron que crearle uno, al principio no volaba. O de Batman y Robin , eternamente jovenes.Entonces a parte de mundos paralelos crearon MultiUniversos, pero eso obligaba a realizar demasiados juegos malabares a la vez para pode controlar todo.Ramascomounabestiacompleja….->En la mayoría de los sistemas de Control de versiones, puedes crear cientos de ramas sin problemas de rendimiento de ningún tipo. Es la sobrecarga mental que mantiene el track de todas las ramas que necesitas y sobre las que realmente estas preocupado. El cerebro de los desarrolladores no se puede actualizar del mismo modo que el sistema de control de versiones así, que hay un serio problema.SolucionPatrones de Ramas!!
- Branch por Release:Una de las estrategias más comunes de ramificación es alinear las ramas con las Release de productos Una rama contiene todos los activos de desarrollo de software para una sola Release. Las ramas mueren cuando la Release se retiran, dejan de tener soporte. En ocasiones, las actualizaciones deben ser mergeadas de una versión a otra.Base de Branch per Release:Contexto:Durante el desarrollode un producto siempre se hacen varias releases de lanzamiento del software. Las releases de trabajo se organizan en torno a las fechas de entrega y sobre sus hitos.Las ramas se tienes que adecuar a esta organización de manera que todo el equipo de desarrollo esté centrado en el objetivo común de sacar cada release.Problema: Como quedaríai esto en el arbol de ramas de releases del proyecto?Que debo hacer:
- .Base de Branch per Release:Contexto:Durante el desarrollode un producto siempre se hacen varias releases de lanzamiento del software. Las releases de trabajo se organizan en torno a las fechas de entrega y sobre sus hitos.Las ramas se tienes que adecuar a esta organización de manera que todo el equipo de desarrollo esté centrado en el objetivo común de sacar cada release.Problema: Como quedaríai esto en el arbol de ramas de releases del proyecto?Que debo hacer:• Sin duda, las etiquetas se utilizan para etiquetar configuraciones estables listas para el lanzamiento. Pero las baselines no son suficientes para ayudar a crer un flujo de trabajo para una versión específica.• Se hacen Liberaciónes de releases de mayor y menor, así como parches para arreglar bugs. Hay mantenimientos y tareas de desarrollo que se producen simultáneamente, en paralelo entre sí.• La integración, es esencial para verificar y validar que una release para ser lanzado es apto para el envío a los clientes, pero puede resultar una tarea muy pesada, al contener por ejemplo releases muy grandes.Soluciones: Para cada entrega prevista (mayor, menor, y los parches), utilizar ramas independientes para organizar los esfuerzos puestos en cada release.Por ejemplo: rama para la V1,1, rama para la V1.2, etc.Planteamiento:Earlybranche: se crea una rama, tan pronto como haya algo para salir.Deferredbranches: solo se hace una nueva rama, cuando los cambios de ese version están todos completos.Por ejemplo, una corrección de errores podría ser necesaria tanto para la release 1.1 como para la 2.0. Con ramificación temprana, de corrección de errores que entraría en tanto el 1,1 y el 2,0 Con Deferred , si el 2,0-line aún existe, la bug-fix entraría en el 1.1-única línea y la creación de la línea 2.0 se aplazaría hasta que se iniciaron los esfuerzos para añadir alguna feature única para la 2.0 donde se metería ese parche.
- Branch por Promoción: cada nivel es una rama permanente. Cuando los cambios estancompletos y estan testeados, entonces empiezan a pasar el nivel de calidad y se promocionan como merges a ramas superiores
- Branch por PromociónContexto: Cadanivelesunaramaindependiente y permante: desarrollo, test, diseñoProblemas: Decidircuandounaramaestálistaparaserpromocionada: porejemplotodos los test creados y funcionando.Esfuerzoparasacaruna release: necesitastodaslasramas perfectas e irpasandoporlasdistintasfases: test, integracion, pase a produccionSoluciones:Con estepatrónpuedesirrealizandoesfuerzos en paralelo: Desarrolloestá en la versión n+2Testeo en la version n+1Mantenimiento en la version nRama porpromociónsignifica mas ramas, mas merges, y másprecisión en la historiateniendoaisladaslastareas. Esnecesariotener un mayor control de tuentorno de desarrollo y de comoestáconfigurado.
- Branch por componente: cada componente nuevo de la arquitectura es una rama independiente. Los componentes nuevos se integran cuando la rama están completos
- Branch por componente: Tambien se puede cambiar componente por subsitema, producto, moduloEl dueño del componente se hace responsible de de tener a puntotodos los elementosrelacionados con un componente: archivos, modulos, subsistemas, etc. Después de un tiempotrabajando se veclaroqueesnecesario el desarrollo en paraleloparacadauno de estoselementos y queportanto la propiedadunica del componentequedaexpuesta a queotros la modifiquen.Problema: comomantener los beneficions de tucomponentesitodospuedentocarlo?Problemas:Si todo el mundoes responsible, nadiees responsibleSi no se puedetocar el codigoinicial, no se llevaránacabonimejoras, ni fixesTener al equipopendiente de quealguienapruebe los cambios o lasmejoras lo quehacees meter retrasos, especialmente en tareascriticas.Solucion:Hacerunalinea de desarrollo principal y crearramasparacadauno de los subsitemas a desarrollar. El propietario con permisos, decide laspoliticas de integracion y merge de estasramas
- Branch por tarea: cada desarrollador hace un rama nueva por cada tarea que va a lanzar. Las tareas se integran en la rama principal cuando se acaban.
- Branch por tarea:Cada desarrollo es una nueva tarea, independiente. Dentro de tareas hablamos de nuevas features, de bugs, El problema podría venir de que siempre necesitamos integrar el desarrollo realizado con la nueva funcionalidad. El problema no sería hacer tanto ramas, como los merges que debo realizar.Problema: ¿cómo se puede trabajar con multiples (en teoria) superposiciones de codigo que van a mi linea principal de desarrollo sin comprometer su integridad y consistencia.?Esto se puede traducir en :Lock excesivos, que provocan esperas largas y ralentinan el trabajo de desarrollo, pudiendo llegar a matar el trabajo en paralelo.Merges, cambios concurrentes que tienen que ser integrados con cuidado para no provocar inconsistencias del codigo.Solucion:Bifurcacionesseparadasparacadatarea. Unavezque la tareaestácompleta: desarrollo, tests, pruebas, validaciones.. se integradentro de la rama principal. Cadadesarrolladortrabaja de maneraaislada en surama, en paralelo. Es el propietario de esarama, puedeaplicarsuspropiaspoliticas, no interfiere con nadie mas. No propagaerrores. RAMA POR TAREA (HACER DEMO)
- Si hemos llegado hasta aquí, también nos hemos dado cuenta de que podemos abusar de las ramas.Igual que hay patrones de ramas, hay antipatrones.“Merge-Paranoia” :Evitas hacer Merges a toda costa, por el miedo que tienes a las consecuencias. Post: http://arialdomartini.wordpress.com/2011/11/02/help-me-because-i-think-martin-fowler-has-a-merge-paranoia/“Help me because Martin Fowler has a Merge Paranoia”“Merge-Mania”Cuando el equipo pasa su tiempo mergeando en vez de desarrollar¿Recordais los merges con SVN? ¿Desde que revisionteniamos que hacerlo?“Big-Bang-Merge”El Merge se retrasa hasta el final de desarrollo, y se intenta mergear todas las ramas de manera simultanea “Never Ending-Merge”Nuncaterminas de mergear,parecequesiempre hay algomás “Wrong-Way-Merge”Cuando se integra la version actual con la versión anterior “Branch-Mania”a situation where branches are created often and for no apparent reason. “Cascading-Branches”a situation where branches are never merged back to the mainline. “Mysterious-Branches”a situation where the purpose of a branch is unknown. “Temporary-Branches”a situation where the purpose of a branch keeps changing and effectively serves as a permanent “temporary workspace”. “Volatile-Branches”a situation where a branch with “unstable” software assets is shared by other branches or merged into another branch. “Development-Freeze”a situation where all development activities are stopped during branching, merging and building new baselines. “Berlin-Wall”A situation where branches are used to divide the development team members, rather than divide the work they are performing.Branches are volatile most of the time while they exist as independent branches, that is the point of having them. The difference is that they should not be shared or merged while they are in an unstable state.----- Notas de la reunión (04/12/12 12:11) -----Haces los mismo merge trabajando en la misma rama
- Si hemos llegado hasta aquí, también nos hemos dado cuenta de que podemos abusar de las ramas.Igual que hay patrones de ramas, hay antipatrones.“Merge-Mania”Cuando el equipo pasa su tiempo mergeando en vez de desarrollar¿Recordais los merges con SVN? ¿Desde que revisionteniamos que hacerlo?“Big-Bang-Merge”El Merge se retrasa hasta el final de desarrollo, y se intenta mergear todas las ramas de manera simultanea “Never Ending-Merge”Nuncaterminas de mergear,parecequesiempre hay algomás “Wrong-Way-Merge”Cuando se integra la version actual con la versión anterior “Branch-Mania”a situation where branches are created often and for no apparent reason. “Cascading-Branches”a situation where branches are never merged back to the mainline. “Mysterious-Branches”a situation where the purpose of a branch is unknown. “Temporary-Branches”a situation where the purpose of a branch keeps changing and effectively serves as a permanent “temporary workspace”. “Volatile-Branches”a situation where a branch with “unstable” software assets is shared by other branches or merged into another branch. “Development-Freeze”a situation where all development activities are stopped during branching, merging and building new baselines. “Berlin-Wall”A situation where branches are used to divide the development team members, rather than divide the work they are performing.Branches are volatile most of the time while they exist as independent branches, that is the point of having them. The difference is that they should not be shared or merged while they are in an unstable state.
- Si hemos llegado hasta aquí, también nos hemos dado cuenta de que podemos abusar de las ramas.Igual que hay patrones de ramas, hay antipatrones.“Big-Bang-Merge”El Merge se retrasa hasta el final de desarrollo, y se intenta mergear todas las ramas de manera simultanea “Never Ending-Merge”Nuncaterminas de mergear,parecequesiempre hay algomás “Wrong-Way-Merge”Cuando se integra la version actual con la versión anterior “Branch-Mania”a situation where branches are created often and for no apparent reason. “Cascading-Branches”a situation where branches are never merged back to the mainline. “Mysterious-Branches”a situation where the purpose of a branch is unknown. “Temporary-Branches”a situation where the purpose of a branch keeps changing and effectively serves as a permanent “temporary workspace”. “Volatile-Branches”a situation where a branch with “unstable” software assets is shared by other branches or merged into another branch. “Development-Freeze”a situation where all development activities are stopped during branching, merging and building new baselines. “Berlin-Wall”A situation where branches are used to divide the development team members, rather than divide the work they are performing.Branches are volatile most of the time while they exist as independent branches, that is the point of having them. The difference is that they should not be shared or merged while they are in an unstable state.
- Si hemos llegado hasta aquí, también nos hemos dado cuenta de que podemos abusar de las ramas.Igual que hay patrones de ramas, hay antipatrones. “Never Ending-Merge”Nuncaterminas de mergear,parecequesiempre hay algomás “Wrong-Way-Merge”Cuando se integra la version actual con la versión anterior “Branch-Mania”a situation where branches are created often and for no apparent reason. “Cascading-Branches”a situation where branches are never merged back to the mainline. “Mysterious-Branches”a situation where the purpose of a branch is unknown. “Temporary-Branches”a situation where the purpose of a branch keeps changing and effectively serves as a permanent “temporary workspace”. “Volatile-Branches”a situation where a branch with “unstable” software assets is shared by other branches or merged into another branch. “Development-Freeze”a situation where all development activities are stopped during branching, merging and building new baselines. “Berlin-Wall”A situation where branches are used to divide the development team members, rather than divide the work they are performing.Branches are volatile most of the time while they exist as independent branches, that is the point of having them. The difference is that they should not be shared or merged while they are in an unstable state.
- Si hemos llegado hasta aquí, también nos hemos dado cuenta de que podemos abusar de las ramas.Igual que hay patrones de ramas, hay antipatrones. “Wrong-Way-Merge”Cuando se integra la versión actual con la versión anterior “Branch-Mania”a situation where branches are created often and for no apparent reason. “Cascading-Branches”a situation where branches are never merged back to the mainline. “Mysterious-Branches”a situation where the purpose of a branch is unknown. “Temporary-Branches”a situation where the purpose of a branch keeps changing and effectively serves as a permanent “temporary workspace”. “Volatile-Branches”a situation where a branch with “unstable” software assets is shared by other branches or merged into another branch. “Development-Freeze”a situation where all development activities are stopped during branching, merging and building new baselines. “Berlin-Wall”A situation where branches are used to divide the development team members, rather than divide the work they are performing.Branches are volatile most of the time while they exist as independent branches, that is the point of having them. The difference is that they should not be shared or merged while they are in an unstable state.