Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Infoshare 2012, prezentacja
Infoshare 2012, prezentacja
Loading in …3
×
1 of 44

[ES] Sistemas de control de versiones

1

Share

Download to read offline

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

[ES] Sistemas de control de versiones

  1. 1. Sistemas de Control de Versiones Eudris B. Cabrera Rodríguez Ingeniero Telemático Desarrollador de Software / Consultor Informático Junio 2013, Santiago de los Caballeros, R. D.
  2. 2. Los conceptos y juicios de valor emitidos en esta presentación son responsabilidad personal y no se puede entender como una posición oficial de alguna empresa con la que he tenido relación laboral. Asuntos Legales Todas las marcas registradas, así como todos los logotipos, imágenes, fotografías, audio y vídeos mostrados en esta presentación son propiedad de sus respectivos propietarios. Su utilización es solamente para fines ilustrativos y no pretendo dar a entender cualquier afiliación con esas empresas. Responsabilidades
  3. 3. Contenido ■ ¿Qué es un sistema de control de versiones ? ■ ¿Cómo funciona ? ■ Prácticas Obsoletas. ■ ¿Porqué son necesarios ? ■ Ventajas. ■ Evolución. ■ Principales sistemas de control de versiones de código abierto. ■ Conclusiones.
  4. 4. ¿Qué es un sistema de control de versiones ? Es un software que administra el acceso a un conjunto de archivos, y mantiene un historial de cambios realizados. El control de versiones es útil para guardar cualquier documento que cambie con frecuencia, como una novela, o el código fuente de un programa.
  5. 5. ¿Cómo funciona ? Normalmente consiste en una copia maestra en un repositorio central, y un programa cliente con el que cada usuario sincroniza su copia local. Esto permite compartir los cambios sobre un mismo conjunto de archivos. Además, el repositorio guarda registro de los cambios realizados por cada usuario, y permite volver a un estado anterior en caso de necesidad.
  6. 6. Flujo de trabajo centralizado
  7. 7. Prácticas Obsoletas Si alguna vez ha colaborado con otras personas en un proyecto, usted sabe la frustración de constante intercambio de archivos. Los programadores a través del tiempo han usado diversos métodos para compartir su código fuente en un ambiente de desarrollo colaborativo, a continuación algunas de las soluciones más usadas:
  8. 8. Realizar copias en diferentes computadoras Mantener un backup en computadoras o servidores diferentes, así como también, guardar copia en disco compactos o disco externos. Si bien es cierto que ésta práctica puede mantener a salvo los códigos fuentes, también es cierto que tiene desventajas a la hora de guardar versiones. En cada modificación que hace al código original debe ir guardando tus propias copias de la versión anterior a la modificación y de la nueva versión.
  9. 9. Crear aplicaciones propias Crear aplicaciones in-house para manejar las versiones de tu código, quizás sea una buena opción pero está reinventando la rueda, ya que existen opciones open source para manejar versiones. El tiempo que debes utilizar para desarrollar una nueva aplicación para estos fines puede utilizarlo en el desarrollo de otro proyecto.
  10. 10. Guardar los fuentes en Dropbox Una solución usadas en los últimos tiempos por los programadores. Dropbox internamente funciona como un manejador de versiones pero tiene sus limitantes en el uso que puede darle un desarrollador. Las soluciones anteriores pueden tener su utilidad y dar resultados aceptables, sin embargo, es recomendable usar una solución general, diseñada para mantener tu código a salvo y de forma centralizada, como lo hacen los sistemas de control de versiones.
  11. 11. ¿Por qué son necesarios? En la sección anterior presentamos algunas prácticas usadas por los programadores y sus desventajas. Todos los sistemas de control de versiones tienen ciertas características que eliminan muchas de las desventajas presentadas anteriormente, entre las cuales podemos mencionar:
  12. 12. Actualiza archivos modificados El cliente recorre nuestro código y sincroniza nuestra copia local con el repositorio. Copias de seguridad centralizadas Solo el administrador debe preocuparse de realizar copias de seguridad en el repositorio. Esto se automatiza fácilmente con una tarea cron [http://www.gnu. org/directory/cron.html] o similares.
  13. 13. Historial de cambios El repositorio guarda registro de todos los cambios realizados. Es posible recuperar cualquiera de las versiones anteriores de cualquier archivo. Si alguien borra todos los archivos, podemos volver atrás y recuperar su contenido.
  14. 14. Acceso remoto Es posible acceder remotamente al repositorio. No es necesario que el equipo esté dentro de la misma LAN. Seguridad Es posible otorgar diferentes permisos sobre diferentes ramas del proyecto. Por ejemplo, estableciendo permiso universal de lectura, y permiso de escritura sólo a ciertos usuarios.
  15. 15. ¿Qué hacer cuando dos usuarios intentan modificar el mismo archivo?
  16. 16. Existen dos opciones ...
  17. 17. 1. Bloqueos (Locks) El usuario bloquea el archivo durante su edición, evitando el acceso concurrente de otros usuarios. Existen varios problemas: el usuario que acapara archivo, el interbloqueo entre usuarios que necesitan varios archivos, y la falta de concurrencia.
  18. 18. 2. Merge (fusión de cambios) los archivos se acceden concurrentemente. Los cambios realizados sobre un mismo archivo son fusionados inteligentemente por el sistema. El único problema es el intento de fusión de cambios incompatibles, que ha de solucionarse manualmente.
  19. 19. Ventajas La mayoría de los desarrolladores probablemente han trabajado con algún tipo de sistema de control de versiones, pero las personas en otras áreas pueden tener un concepto extraño. La ventaja más obvia de usar control de versiones es la posibilidad de tener un número ilimitado de personas que trabajan en la misma base de código, sin tener que enviar constantemente los archivos de ida y vuelta.
  20. 20. Desarrolladores y otros profesionales que manejan archivos a los cuales se le realizan cambios constantemente, pueden beneficiarse del uso de los sistemas de control de versiones para guardar copias de sus archivos, diseños, libros, etc. Usted puede navegar por los cambios anteriores realizado a su repositorio y volver a versiones anteriores si pasa algo.
  21. 21. Evolución
  22. 22. Principales sistemas de control de versiones de código abierto
  23. 23. CVS Concurrent Versions System Desarrollador: The CVS Team Url: savannah.nongnu.org/projects/cvs Lanzamiento inicial : 19 de Noviembre de 1990 Programado en C. Sistema operativo: Unix-like, Windows Licencia: GNU General Public License (GPL) Esquema de trabajo
  24. 24. CVS Es el abuelo de los sistemas de control de versiones. Fue lanzado por primera vez en 1986. CVS tuvo el mérito de ser el primer sistema usado por el movimiento de código abierto para que los programadores colaborarán remotamente mediante el envío de parches. Es de uso gratuito, código abierto, y emplea fusión de cambios. Aunque CVS puede ser una tecnología antigua, todavía es muy útil para realizar copias de seguridad y compartir archivos.
  25. 25. SVN Desarrollador: Comunidad, y desarrolladores de CollabNet, Elego, VisualSVN, WANdisco Url: http://subversion.apache.org Lanzamiento inicial : 20 de octubre de 2000 Programado en C. Sistema operativo: Multiplataforma Licencia: Licencia Apache Flujo de trabajo centralizado
  26. 26. Subversion se creó para igualar y mejorar la funcionalidad de CVS, preservando su filosofía de desarrollo. Su desarrollo comenzó en el año 2000 como proyecto de código abierto apadrinado por CollabNet. El líder del equipo de desarrollo fue Karl Fogel, autor de Open Source Development with CVS y fundador de Cyclic Software (compañía de desarrollo y soporte comercial para CVS.
  27. 27. Probablemente sea el sistema de control de versiones con la adopción más amplia. La mayoría de los proyectos de código abierto utiliza Subversion como repositorio. Google Code utiliza Subversion exclusivamente para distribuir código. Otros proyectos de mayor envergadura, como SourceForge, Apache, y muchos otros también lo utilizan.
  28. 28. GIT Desarrollador: Junio Hamano, Linus Torvalds Url: http://git-scm.com Diseñador: Linus Torvalds Programado en C, Bourne Shell, Perl1 Licencia : GNU GPL v2 Flujos de trabajo distribuidos
  29. 29. Es la nueva estrella de los sistemas de control de versiones. Inicialmente diseñado y desarrollado por Linus Torvalds para el desarrollo del Kernel de Linux, desde ese entonces, ha sido adoptado por otros proyectos. Git se enorgullece de ser un sistema rápido y eficaz, muchos proyectos de código abierto importantes utilizan Git para alimentar sus repositorios, proyectos como: Linux Kernel, WINE, Fedora y muchos más.
  30. 30. Git ofrece un tipo de control de versiones diferente, un sistema de control distribuido de versiones. Con un sistema de control de versiones distribuido, no hay una sola base de código centralizada para tirar el código. Diferentes ramas sostienen las diferentes partes del código. Otros sistemas de control de versiones, como SVN y CVS, utilizar el control de versiones centralizado, lo que significa que sólo se utiliza una copia original del software.
  31. 31. GitHub ha ayudado recientemente a establecer Git como un gran sistema de control de versiones, ofreciendo una hermosa interfaz para muchos proyectos grandes, como Ruby on Rails, Netty y otros más. Sin embargo, Git no es tan fácil de aprender como CVS o SVN, así que es mucho más difícil de usar para un principiante. Más información en: https://github.com
  32. 32. Mercurial Desarrollador: Matt Mackall Url: http://mercurial.selenic.com Programado en Python y C Sistema operativo: Tipo Unix, Windows, Mac OS X Licencia : GPL v2 Esquema de trabajo
  33. 33. Es otro sistema de control de versiones distribuidos de código abierto, como Git. Mercurial fue diseñado para proyectos más grandes, probablemente fuera del alcance de los diseñadores y desarrolladores web independientes. Eso no quiere decir que los equipos de desarrollo pequeños no pueden o no deben utilizarlo. Mercurial es muy rápido, y fue diseñado con el rendimiento como la característica más importante.
  34. 34. Aparte de ser muy rápido y escalable, Mercurial es un sistema mucho más simple que Git, por lo que atrae a algunos desarrolladores. No hay tantas funciones para aprender, y las funciones son similares a los de otros sistemas de CVS. También viene equipado con una interfaz Web independiente y amplia documentación en la comprensión de Mercurial si usted ha estado utilizando otro sistema.
  35. 35. Bazaar Desarrollador: Canonical Ltd. y comunidad Url: bazaar.canonical.com Diseñador: Martin Pool Lanzamiento inicial: 14 de diciembre de 2007 Programado en Python, Pyrex, C Sistema operativo: Multiplataforma Licencia: GPLv2 o superior1 (software libre) Flujo de trabajo
  36. 36. Es otro sistema distribuido de control de versiones, como Mercurial y Git, que ofrece una experiencia de usuario muy amigable. Se llama a sí mismo "El control de versiones para los seres humanos." Es compatible con muchos tipos diferentes de flujos de trabajo, con muchas variaciones entre ellos. Se trata de un gran sistema de control de versiones para casi cualquier proyecto, ya que es fácil de modificar.
  37. 37. También es integrable, por lo que puede agregar a los proyectos existentes. Bazaar también tiene una comunidad fuerte que mantiene cosas como plug-ins y un montón de herramientas de terceros.
  38. 38. Bazaar es usado por miles de proyectos, incluyendo a : GNU BugZilla Debian LaunchPad Linux Foundation MariaDB Inkscape
  39. 39. Popularidad ZeroTurnaround Developer Productivity Report 2012
  40. 40. Recursos CVS: http://cvs.nongnu.org/ http://en.wikipedia.org/wiki/Concurrent_Versions_System SVN: http://subversion.tigris.org/ http://code.google.com/ http://www.beanstalkapp.com/ http://en.wikipedia.org/wiki/Apache_Subversion
  41. 41. Git http://en.wikipedia.org/wiki/Git_(software) https://git.wiki.kernel.org/index.php/GitSvnComparsion Mercurial http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial http://en.wikipedia.org/wiki/Mercurial Bazaar: http://bazaar-vcs.org/ http://bazaar-vcs.org/Workflows http://doc.bazaar-vcs.org/latest/en/tutorials/using_bazaar_with_launchpad.html
  42. 42. Conclusiones ■ Desarrollar un software implica invertir mucho tiempo y dinero. No proteger el código fuente con un sistema de control de versiones es irresponsable y puede traer graves consecuencias. ■ Cualquier persona que trabaje con archivos que son sometidos a cambios constantemente pueden beneficiarse del uso de los sistemas de control de versiones para guardar copias de sus archivos, diseños, libros, etc. ■ Existen sistemas de control de versiones de código abierto, libre distribución y amplia documentación, lo que permite su fácil implementación y curva de aprendizaje.
  43. 43. Referencias Distributed Source Control Management systems http://blog.tfnico.com/2010/06/distributed-source-control-management.html 7 Version Control Systems Reviewed http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version- control-systems/ Libro Version Control with Subversion (Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato). Ensayo "Subversion" de Alejandro Ramírez
  44. 44. Email: eudris@gmail.com Skype: eudriscabrera LinkedIn: http://www.linkedin.com/in/eudriscabrera GitHub: https://github.com/ecabrerar

×