T©cnicas avanzadas de control de versiones

download T©cnicas avanzadas de control de versiones

of 36

  • date post

    30-Jun-2015
  • Category

    Software

  • view

    342
  • download

    0

Embed Size (px)

description

Se exponen buenas prácticas para realizar el control de versiones, las ramas y los merges de nuestros proyectos en Subversion.

Transcript of T©cnicas avanzadas de control de versiones

  • 1. ngel Armenta Martnezarmenta.angel@gmail.com@armenta_angel

2. Qu vamos a ver hoy? Repasaremos las buenas prcticas generales a lahora de usar el sistema de control de versiones. Hablaremos del uso de las ramas y la convenienciadel uso de las mismas. Perderemos el miedo a realizar merges. Veremos demos de lo expuesto.Podis ver y descargar esta presentacin en [link slideshare] 3. Por qu se ha elegido Subversion y TortoiseSVNpara esta presentacin? SVN es el software de control de versiones ms usadoen entornos empresariales. Se supone por tanto que la mayora de los asistenteslo usan, lo han usado o lo usarn. TortoiseSVN es una de las herramientas visuales mspotentes y maduras para operar contra el repositoriode SVN. Dispone de un sistema de merges muyavanzado.De todos modos, prcticamente todo lo expuesto es extrapolable a cualquier otrosistema de control de versiones. 4. Estructurar correctamente el repositorio (1/2)Existen muchas maneras vlidas de estructurar nuestro repositorio, perooficialmente Subversion recomienda una raz por proyecto/aplicacinque contiene al menos los siguientes subdirectorios: /trunk, /branches y/tags: 5. Estructurar correctamente el repositorio (2/2) Trunk: Aqu debe estar la versin actual y estable del proyecto. Es tambinllamada la rama de produccin. Debe permanecer estable y complilableSIEMPRE. Tags: Denotan puntos especficos en el historial de un proyecto (hitos), como porejemplo entregas a produccin. Son puntos de referencia y nunca debetrabajarse sobre ellos y modificar su contenido. Branches: Se usa para trabajar en los cambios del proyecto paralelamente a larama principal (trunk) evitando as romper la versin estable del proyecto. 6. El repositorio de SVN no es un backup No pensar que SVN es nuestro sistema de backup. Procurarno realizar commits simplemente para guardar el trabajopor razones como he terminado mi jornada laboral y voy aguardar. Si lo necesitramos, recurrir a otras opciones comopor ejemplo Dropbox. Cuando hacemos commit, lo que debemos estar haciendo esgenerando una nueva versin estable, con nuevafuncionalidad, etc. 7. Cundo hacer commit? No se debe hacer commit ni cada lnea que se programe ni al finalde la jornada. Se debe hacer un commit tan pronto como los cambios conformenuna unidad lgica funcional, teniendo en cuenta que nunca debenromper la compilacin. Estas unidades lgicas deberan acotarse para que los commits sevayan realizando de manera regular y no impliquen un lote muygrande de cambios en el repositorio, ya que de lo contrariopodramos encontrarnos con un escenario de conflictos con losdesarrollos de otros miembros del equipo que podran llegar a sermuy difciles de resolver. 8. Comentarios (1/2): precisos y exhaustivos Todo commit debe tener su comentario. El comentario debe ser preciso y exhaustivo. Se debeexplicar correctamente lo que se ha realizado en elcommit. Es buena prctica tambin marcar los commits de eventoscomo la creacin de branches, tags y merges de maneraestandarizada en el equipo. Por ejemplo, que elcomentario de la apertura de un nuevo branch vayaprecedido por la etiqueta [BRANCH]. Igualmente se puedeestandarizar que el comentario indique la versin desde laque se abre la rama. 9. Comentarios (2/2): ejemplos [BRANCH] Nueva rama creada para el desarrollo de (evolutivo X,correccin Y, etc.), a partir de la rama (Indicar rama), revisin (indicarnmero de revisin en SVN). [TAG] Versin instalada en produccin el 20-10-2014 en el PaP de(la versin X.Y.Z, el evolutivo X, etc). [MERGE] Fusionamos las revisiones 9234, 9231, 9311-9412 de larama branches/correctivos-v1.4.Otras etiquetas pueden ser el cdigo de incidencia del sistema de bug tracking, elcdigo de proyecto, o combinaciones de estos:[jira-1231], [HOME2013-5023], [EMP2014-3459/jira-86], etc. 10. Ejecutando el commit (1/2)1. Antes de subir nada, revisar si antes otra persona ha subidocambios al repositorio, realizando un update. Si existen cambiosa descargar, pueden entrar en conflicto con los nuestros. En esecaso, debemos resolver esos conflictos antes de subir nuestroscambios.2. Revisar los cambios a commitear, procurando no subirbinarios, archivos innecesarios de configuracin, etc. Puede sernecesario usar la funcin add to ignorelist.3. Recuerda que el commit ser atmico. Todos los cambioscontenidos en el subirn, o no subir nada. Es decir, un nmerode revisin contendr cambios en uno o mltiples ficheros y/o enla estructura. 11. Ejecutando el commit (2/2) 12. Actualizarse la rama de trabajo a menudo Es conveniente actualizarse la rama de trabajo a menudo paraincorporar en ella los cambios que otros miembros del equipohayan realizado sobre la misma. De esta manera reduciremos lasposibilidades de conflictos con otros commits a la hora de subirnuestros cambios, evitando la resolucin de los mismos, la cual enocasiones puede ser complicada. Si vamos a empezar a trabajar en una rama que habamosdescargado hace ya un tiempo, lo primero que debemos hacer esactualizarla. Por supuesto como ya hemos comentado, siempre antes de uncommit. 13. No subir ficheros innecesarios al repositorio Los binarios resultado de compilar los fuentes, p.e. en Java los .class Los instalables finales fruto de la compilacin de una librera, componente odirectamente el proyecto completo, p.e. lib-accesobd-1.3.jar, facebook.war. Los archivos de log que genera nuestra aplicacin cuando la hemos puesto enmarcha en nuestro equipo mientras desarrollbamos o bien mientraslanzbamos los tests. En definitiva, cualquier archivo que genere automticamente la compilacin opuesta en marcha del proyecto.Existen recomendaciones de no subir al repositorio ficheros de configuracin delentorno de trabajo como los IDEs (p.e. en Eclipse el .classpath, .project, etc.).Yo personalmente no tengo problema en ello, de hecho me parece beneficioso enequipos donde todos o varios de sus miembros usan el mismo IDE. 14. Demo 15. Una etiqueta o tag no es ms que una instantnea(snapshot) del proyecto en tomada en un momentoconcreto. Se pueden tomar en cualquier rama de trabajo. Se crean exactamente igual que una rama, sin embargo,no deben utilizarse para realizar modificaciones, debenpermanecer inalteradas. Se recomienda almacenarlas bajo el directorio /tags delrepositorio. Normalmente se usan para marcar versiones entregadasen produccin, p.e. release-1.0, aunque podemos marcarcualquier otra revisin de inters como p.e. organizar lasversiones entregas para pruebas. 16. Hay quien las evita Dificultad de gestin de las mismas y sobretodo pnico almomento en el que hay que realizar el merge. Se puede incluso encontrar textos y manuales de autores queexplcitamente piden que se eviten. Sin miedo Son la solucin para mantener segura la rama de produccin,mientras desarrollamos nuevas funcionalidades, parches yevolutivos. Las herramientas existentes a da de hoy para realizar mergesson muy buenas y mejores que nosotros tratando de realizar losmerges a mano. Facilitan la resolucin de conflictos. Aumentarn nuestra productividad y nos permitirn dar alcliente ms opciones para realizar entregas del proyecto. 17. Escenario bsico (1/2) El escenario ms bsico, es el de una rama de produccin o Trunk desde la cual se abrenotras ramas en las cuales s pueden estar desarrollando funcionalidades en paralelo (6,7). Los cambios de las ramas se van integrando en el Trunk (flechas verdes) cuando sealcancen hitos en el desarrollo que deban subir a produccin. Cuando tenemos ramas en paralelo, puede ser necesario que ests reciban cambios quese han llevado al Trunk (flecha verde 10-11) En ocasiones querremos marcar con un tag hitos como una entrega real en produccino la referencia a una fusin de cambios (5, 13). Aunque una rama haya llevado sus cambios al Trunk, podemos seguir avanzando sobreella o bien discontinuarla sin ms (15, 16). 18. Escenario bsico(2/2) Una pequea vuelta de tuerca a lo expuesto en la transparencia anterior. Los puntos sobre las ramas representan commits (establecen una revisin en SVN). Las lneasnegras en realidad representan un tag. No hay desarrollo sobre ellas. Ramas en paralelo en las que las que se ha realizado una divisin de desarrollos porfuncionalidades. A y B completan la R1 y cuando terminamos la C se completa la R2. Vemos como tras aplicar cambios en la rama Main, estos son volcados sobre las ramas condesarrollos en curso. Cierto es que la dificultad de gestionar correctamente las ramas crece exponencialmente enfuncin de su nmero. 19. Escenario avanzado (1/6) 20. Escenario avanzado (2/6) Principales ramas: Master (Trunk, Prod,) Develop (prj-a, prj-b,) La rama Master recibe cambiosde la(s) rama(s) Develop. Estos cambios coinciden con lageneracin de una nuevarelease (p.e. 0.1, 0.2, ). 21. Escenario avanzado (3/6) Feature branches: Cuelgan de la rama develop. Se pueden abrir en paralelo varias f.b.desde cualquier punto de la ramadevelop. Los cambios de las f.b. se fusionaranen la rama develop cuando estnlistos. La rama f.b. fusionada quedarobsoleta. Es un caso atpico que las f.b. recibancambios (merge) desde la ramadevelop. Sin embargo puede llegar adarse si fuese necesario incluirlos siafectase al desarrollo y/o pruebas dela f.b. 22. Escenario avanzado (4/6) Hotfixes branches: Si se descubre un bugimportante en la versin Master(versin de produccin), seabrir una rama de hotfixespara su correccin. Una vez terminada lacorreccin, se aplicar en larama Master. Esta correccin tambin tendrque ser llevada a la/s rama/sdevelop y de esta/s a sus f.b. sifuera conveniente. 23. Escenario avanzado (5/6) Release branches: El cumplimiento de ciertos hitos dedesarrollo en la rama develop puedeconformar una nueva release. La nueva release puede que no vaya asubir a produccin todava y que tengaque crearse una r.b. Sobre dicha r.b. solo se corregiranbugs de la funcionalidad esperada en larelease. Los cambios en la r.b. se iranfusionando en la/s rama/s develop,nunca al contrario, ya que se suponeque una r.b. contiene una serie defuncional