Your SlideShare is downloading. ×
Git y Jenkins. El futuro en la gestión del ciclo de vida de aplicaciones
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Git y Jenkins. El futuro en la gestión del ciclo de vida de aplicaciones

4,987
views

Published on

Git es un sistema de control de versiones distribuido. Jenkins es un sistema de integración contínua. …

Git es un sistema de control de versiones distribuido. Jenkins es un sistema de integración contínua.

Esta presentación es el material de un seminario de impartido por Juan José Fidalgo de @paradigmate el 17 de mayo del 2012 en Escuela Politécnica Superior de la Universidad CEU San Pablo en Madrid.

La aplicación práctica de la presentación se sigue mejor con un cliente por línea de comandos, por ejemplo con el plugin eGit en el entorno de desarrollo Eclipse.

Más información en http://www.paradigmatecnologico.com/git-y-jenkins-el-futuro-en-la-gestion-del-ciclo-de-vida-de-aplicaciones/ y http://www.javahispano.org/portada/2012/4/25/seminario-gratuito-sobre-git-y-jenkins.html

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,987
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
113
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Spring Roo &Spring Insight @federicojcdm 14 de Octubre de 2010
  • 2. ¿Qué es Git? Fue diseñado por Linus Torvalds Git es un sistema de control de versiones distribuido. En oposición a un sistema de control de versiones centralizado, Git, da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Git da un fuerte soporte al desarrollo no lineal, y, proporciona mecanismos simples y eficaces para la gestión y mezclado de ramas. Git permite trabajar con una menor dependencia del repositorio central, en comparación con sistemas de control de versiones como CVS o SVN. 2
  • 3. Distribuido vs Centralizado I En un sistema de control de versiones centralizado, como pueden ser CVS o SVN, el historial de versiones está alojado en el repositorio central. A partir de una copia local del repositorio no es posible reconstruir el repositorio de nuevo. En uno distribuido, como Git, cada copia local del repositorio, contiene el historial completo de versiones. Es posible montar un nuevo repositorio, sin pérdida alguna de información, a partir de cualquiera de las copias locales. En un sistema de control de versiones centralizado, la mayoría de las operaciones, incluida la gestión de versiones, requieren de conexión al repositorio central. En uno distribuido, un gran número de operaciones, incluido el control de versiones de los elementos, se puede realizar sin conexión con el repositorio central. 3
  • 4. Distribuido vs Centralizado II En un sistema de control de versiones centralizado, se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable. En uno distribuido no es necesario tomar decisiones centralizadamente. En sistemas de control de versiones centralizados como CVS o SVN, la creación, mergeado o gestión de ramas es algo muy dependiente del repositorio central, y, que es tratado como algo no habitual. En Git, la creación, mergeado o gestión de ramas, es algo que puede hacerse en caso de ser necesario sin ningún tipo de dependencia del repositorio central, y, es tratado como algo natural y habitual. 4
  • 5. Instalación de un cliente de Git Existen versiones del cliente Git para Windows, Mac OSX, y Linux El cliente puede ser descargado desde desde http://git-scm.com/ Desde http://git-scm.com/ puede descargarse un .exe para Windows Desde http://git-scm.com/ puede descargarse un .dmg para Mac OSX Desde http://git-scm.com/ pueden descargarse los fuentes para Linux En las distintas distribuciones de Linux, suele existir un paquete precompilado del cliente de Git, así, por ejemplo, para instalar la versión precompilada del cliente Git en algunas distribuciones Linux, – En Ubuntu: apt-get install git-core Ubuntu – En Fedora: yum install git-core Fedora 5
  • 6. Manejo Básico Cliente Git I Creando un nuevo repositorio local de Git Añadiendo elemento al índice de Git 6
  • 7. Manejo Básico Cliente Git II Comando status Realizando commit 7
  • 8. Manejo Básico Cliente Git III Consultando el historial de commit Consultando cambios realizados 8
  • 9. Manejo Básico Cliente Git IV Volviendo a una versión anterior temporalmente 9
  • 10. Manejo Básico Cliente Git V Regresando de una versión anterior 10
  • 11. Manejo Básico Cliente Git VI Volviendo a una versión anterior definitivamente 11
  • 12. Git en el servidor: Gitosis Gitosis es una herramienta que nos ofrece la posibilidad de controlar el acceso a los repositorios Git. Gitosis gestiona múltiples repositorios con una sola cuenta de usuario en el servidor, utilizando claves SSH para identificar a los usuarios. Con Gitosis, para los usuarios de los repositorios Git, no será necesario que tengan una cuenta de usuario en el servidor, sino que se gestionará el control de acceso de forma completamente transparente a ellos. Es de fácil instalación y configuración. Puede verse un ejemplo de instalación y configuración de Gitosis en la siguiente url, http://ymbra.com/es/blog/ramon/gestion-de-repositorios-git-con- gitosis 12
  • 13. Git en el servidor: GitHub GitHub (https://github.com/) es una alternativa de un tercero que permite gestionar proyectos Git. GitHub es gratuito para proyectos open source, y en esta modalidad, únicamente permite operar con repositorios públicos. GitHub permite operar con repositorios privados, pero, a través de cuentas de pago. GitHub es una alternativa interesante para aquellas empresas que quieran utilizar repositorios Git, sin tener que preocuparse de habilitar un servidor Git, administrarlo, gestionar backups, seguridad, …... 13
  • 14. Git en el servidor: Configuración GitHub Ir a https://github.com/ Ir a la opción “Signup and Pricing” Ir a la opción “Create a free account” Rellenar datos Acceder 14
  • 15. Git en el servidor: Generación SSH keys Para la creación de un par de claves(clave pública/clave privada) SSH se seguirá el siguiente procedimiento, 15
  • 16. Git en el servidor: Acceso SSH GitHub Localizar en el sistema local la clave pública generada (id_rsa.pub) Acceder a la cuenta de GitHub Ir a opción “Account Settings” Seleccionar opción “SSH Keys” Añadir la clave pública (id_rsa.pub) mediante la opción “Add SSH Key” 16
  • 17. Git en el servidor: Creación de Repositorios Acceder a la cuenta de GitHub Seleccionar opción “New Repository” Completar datos del nuevo repositorio, y crear repositorio 17
  • 18. Git en el servidor: Subir Repositorio a GitHub Copiar ruta del repositorio remoto que se obtuvo al crear el repositorio en GitHub. En el sistema local, sobre el repositorio Git, añadir la ruta del repositorio remoto de GitHub Subir cambios locales a repositorio remoto (push) 18
  • 19. Git en el servidor: Actualizar desde Repositorio Para realizar una actualización del repositorio local contra el repositorio remoto, no debe de haber cambios por commitear. Puede comprobarse si existen cambios por commitear, mediante la ejecución de “git status”. En caso de existir cambios por commitear, antes de realizar la actualización contra el repositorio remoto pueden tomarse dos acciones posibles – Commitear los cambios pendientes – Realizar “git stash”, que guardará los cambios desde el último commit en una pila para tal efecto, y, situará el estado del repositorio local en el del último commit que fue realizado. Con posterioridad a realizar la actualización desde el repositorio remoto, podrá ejecutarse “git pop”, para realizar un merge entre lo que fue almacenado en la pila, y, lo que ha sido actualizado desde el repositorio remoto. Para realizar la actualización desde el repositorio remoto, que realizará un merge entre la versión del repositorio local, y, la versión del repositorio remoto. En caso de existir conflictos en el merge, Git tratará de resolverlos automáticamente, si no puede resolverlos automáticamente informará de ello, para que sean resueltos manualmente. 19
  • 20. Git en el servidor: Clonado de Repositorios Acceder a la cuenta de GitHub Obtener la url SSH del repositorio remoto a clonar Realizar clonado del repositorio remoto en sistema local 20
  • 21. Git en el servidor: Otros protocolos en GitHub I Accediendo al repositorio GitHub por https 21
  • 22. Git en el servidor: Otros protocolos en GitHub II Accediendo al repositorio GitHub read-only 22
  • 23. Gestión de Branch con Git I Un proyecto puede ser branched o bifurcado en un instante de tiempo de forma que, desde ese momento en adelante, dos copias de los ficheros de ese proyecto puedan ser desarrolladas a diferentes velocidades o de diferentes formas, de modo independiente. El proyecto tiene entonces 2 (o más) "ramas". La ventaja es que se puede hacer un "merge" de las modificaciones de ambas ramas, posibilitando la creación de "ramas de prueba" que contengan código para evaluación, si se decide que las modificaciones realizadas en la "rama de prueba" sean preservadas, se hace un "merge" con la rama principal, o entre dos ramas cualquiera. Cualquier repositorio de Git, al ser inicializado, crea automáticamente una rama por defecto, que recibe el nombre de rama master, y que suele ser usada como rama principal. 23
  • 24. Gestión de Branch con Git II Listando los branches existentes, Creando un nuevo branch en el repositorio local, Cambiando al nuevo branch en el repositorio local, 24
  • 25. Gestión de Branch con Git III Creando un nuevo branch en repositorio local, y, quedar situado en el nuevo branch 25
  • 26. Gestión de Branch con Git IV Realizando merge entre dos branch, 26
  • 27. Gestión de Branch con Git V Subiendo branch del repositorio local al servidor, 27
  • 28. Gestión de Branch con Git VI Borrando branches locales, 28
  • 29. Gestión de Branch con Git VII Trayendo branches desde el servidor al repositorio local, 29
  • 30. Gestión de Branch con Git VIII Borrando branches en el servidor, 30
  • 31. egit: Creando un Repositorio Local I 31
  • 32. egit: Creando un Repositorio Local II 32
  • 33. egit: Creando un Repositorio Local III 33
  • 34. egit: Añadiendo Elementos al Índice de Git I 34
  • 35. egit: Añadiendo Elementos al Índice de Git II 35
  • 36. egit: Añadiendo Elementos al Índice de Git III 36
  • 37. egit: Añadiendo Elementos al Índice de Git IV 37
  • 38. egit: Haciendo commit I 38
  • 39. egit: Haciendo commit II 39
  • 40. egit: Mostrando Historia de un elemento I 40
  • 41. egit: Mostrando Historia de un elemento II 41
  • 42. egit: Ir a una versión anterior temporalmente 42
  • 43. egit: Regresando de una versión anterior 43
  • 44. egit: Ir a una versión anterior definitivamente 44
  • 45. egit: Configurando repositorio remoto I 45
  • 46. egit: Configurando repositorio remoto II 46
  • 47. egit: Configurando repositorio remoto III 47
  • 48. egit: Configurando repositorio remoto IV 48
  • 49. egit: Configurando repositorio remoto V 49
  • 50. egit: Configurando repositorio remoto VI 50
  • 51. egit: Subir cambios locales a repositorio remoto 51
  • 52. egit: Actualizando desde repositorio remoto 52
  • 53. egit: Clonado de repositorios I 53
  • 54. egit: Clonado de repositorios II 54
  • 55. egit: Clonado de repositorios III 55
  • 56. egit: Clonado de repositorios IV 56
  • 57. egit: Clonado de repositorios V 57
  • 58. egit: Clonado de repositorios VI 58
  • 59. egit: Creando nuevo Branch I 59
  • 60. egit: Creando nuevo Branch II 60
  • 61. egit: Creando nuevo Branch III 61
  • 62. egit: Realizando merge entre dos ramas I 62
  • 63. egit: Realizando merge entre dos ramas II 63
  • 64. egit: Realizando merge entre dos ramas III 64
  • 65. egit: Realizando merge entre dos ramas IV 65
  • 66. egit: Subiendo branch local al servidor I 66
  • 67. egit: Subiendo branch local al servidor II 67
  • 68. egit: Borrando branch local 68
  • 69. egit: Trayendo branch del servidor a local I 69
  • 70. egit: Trayendo branch del servidor a local II 70
  • 71. egit: Trayendo branch del servidor a local III 71
  • 72. egit: Trayendo branch del servidor a local IV 72
  • 73. egit: Trayendo branch del servidor a local V 73
  • 74. egit: Borrando brach en el servidor I 74
  • 75. Sistemas de Integración continua Metodología informática propuesta inicialmente por Martin Fowler. Consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes. Se entiende por integración la compilación y ejecución de tests de todo un proyecto. 75
  • 76. Presentación Jenkins Jenkins es un software de Integración continua open source escrito en Java. Es un fork del proyecto Hudson. Jenkins corre en un servidor de aplicaciones. Soporta herramientas de control de versiones como CVS, Subversion, Git, Mercurial, Perforce y Clearcase. Puede ejecutar proyectos basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch de Windows. Liberado bajo licencia MIT. 76
  • 77. Instalación de Jenkins Jenkins puede descargarse desde http://jenkins-ci.org/ Instalar la aplicación jenkins.war en un servidor. Acceder consola de Jenkins 77
  • 78. Configuración básica de Jenkins I Acceder opción administrar Jenkins/Configuración del sistema 78
  • 79. Configuración básica de Jenkins II Configurar seguridad 79
  • 80. Configuración básica de Jenkins III Configurar JDK 80
  • 81. Configuración básica de Jenkins IV Configurar Maven 81
  • 82. Configuración básica de Jenkins V Configurar Mail 82
  • 83. Integración Jenkins – Git I Instalar plugin de Git 83
  • 84. Integración Jenkins – Git II Configuración plugin de Git 84
  • 85. Configuración tarea Jenkins I Crear nueva tarea 85
  • 86. Configuración tarea Jenkins II 86
  • 87. Configuración tarea Jenkins III 87
  • 88. Importancia del Testing en Integración continua Sin testing en nuestro proyecto, un sistema de integración continua únicamente probará que nuestro proyecto compila. A medida que añadimos pruebas unitarias/integración a nuestro proyecto, en cada compilación desde el sistema de integración continua se ejecutan la pruebas. Cuanto más pruebas unitarias/integración existan en nuestro proyecto, más eficaz es un sistema de integración continua, ya que será más sencillo que se detecten errores que se ha subido al repositorio. 88
  • 89. Emma Emma permite medir el grado de coverage que las pruebas unitarias/integración hacen a nuestro código. Emma nos muestra que partes del código y cuales no están cubiertas por nuestras pruebas unitarias/integración. Emma nos da una idea de la calidad del testing que estamos realizando. Existe un plugin de Emma que integra con Jenkins. Existe un plugin de Emma que integra con Eclipse: EclEmma. 89
  • 90. MadridAvda. de Europa, 26 - Ática 5,  3ª Planta 28224 Pozuelo de AlarcónE-mail: info@paradigmatecnologico.com Teléfono: +34 91 352 59 42 Fax: +34 91 715 89 66

×