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

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

Transcript

1. Spring Roo & Spring Insight @federicojcdm 14 de Octubre de 2010
2. 2  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. ¿Qué es Git?
3. 3  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. Distribuido vs Centralizado I
4. 4  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. Distribuido vs Centralizado II
5. 5  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 En Ubuntu: apt-get install git-core – En Fedora En Fedora: yum install git-core Instalación de un cliente de Git
6. 6  Creando un nuevo repositorio local de Git  Añadiendo elemento al índice de Git Manejo Básico Cliente Git I
7. 7  Comando status  Realizando commit Manejo Básico Cliente Git II
8. 8  Consultando el historial de commit  Consultando cambios realizados Manejo Básico Cliente Git III
9. 9  Volviendo a una versión anterior temporalmente Manejo Básico Cliente Git IV
10. 10  Regresando de una versión anterior Manejo Básico Cliente Git V
11. 11  Volviendo a una versión anterior definitivamente Manejo Básico Cliente Git VI
12. 12  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 Git en el servidor: Gitosis
13. 13  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, …... Git en el servidor: GitHub
14. 14  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 Git en el servidor: Configuración GitHub
15. 15  Para la creación de un par de claves(clave pública/clave privada) SSH se seguirá el siguiente procedimiento, Git en el servidor: Generación SSH keys
16. 16  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” Git en el servidor: Acceso SSH GitHub
17. 17  Acceder a la cuenta de GitHub  Seleccionar opción “New Repository”  Completar datos del nuevo repositorio, y crear repositorio Git en el servidor: Creación de Repositorios
18. 18  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) Git en el servidor: Subir Repositorio a GitHub
19. 19  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. Git en el servidor: Actualizar desde Repositorio
20. 20  Acceder a la cuenta de GitHub  Obtener la url SSH del repositorio remoto a clonar  Realizar clonado del repositorio remoto en sistema local Git en el servidor: Clonado de Repositorios
21. 21  Accediendo al repositorio GitHub por https Git en el servidor: Otros protocolos en GitHub I
22. 22  Accediendo al repositorio GitHub read-only Git en el servidor: Otros protocolos en GitHub II
23. 23  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. Gestión de Branch con Git I
24. 24  Listando los branches existentes,  Creando un nuevo branch en el repositorio local,  Cambiando al nuevo branch en el repositorio local, Gestión de Branch con Git II
25. 25  Creando un nuevo branch en repositorio local, y, quedar situado en el nuevo branch Gestión de Branch con Git III
26. 26  Realizando merge entre dos branch, Gestión de Branch con Git IV
27. 27  Subiendo branch del repositorio local al servidor, Gestión de Branch con Git V
28. 28  Borrando branches locales, Gestión de Branch con Git VI
29. 29  Trayendo branches desde el servidor al repositorio local, Gestión de Branch con Git VII
30. 30  Borrando branches en el servidor, Gestión de Branch con Git VIII
31. 31 egit: Creando un Repositorio Local I
32. 32 egit: Creando un Repositorio Local II
33. 33 egit: Creando un Repositorio Local III
34. 34 egit: Añadiendo Elementos al Índice de Git I
35. 35 egit: Añadiendo Elementos al Índice de Git II
36. 36 egit: Añadiendo Elementos al Índice de Git III
37. 37 egit: Añadiendo Elementos al Índice de Git IV
38. 38 egit: Haciendo commit I
39. 39 egit: Haciendo commit II
40. 40 egit: Mostrando Historia de un elemento I
41. 41 egit: Mostrando Historia de un elemento II
42. 42 egit: Ir a una versión anterior temporalmente
43. 43 egit: Regresando de una versión anterior
44. 44 egit: Ir a una versión anterior definitivamente
45. 45 egit: Configurando repositorio remoto I
46. 46 egit: Configurando repositorio remoto II
47. 47 egit: Configurando repositorio remoto III
48. 48 egit: Configurando repositorio remoto IV
49. 49 egit: Configurando repositorio remoto V
50. 50 egit: Configurando repositorio remoto VI
51. 51 egit: Subir cambios locales a repositorio remoto
52. 52 egit: Actualizando desde repositorio remoto
53. 53 egit: Clonado de repositorios I
54. 54 egit: Clonado de repositorios II
55. 55 egit: Clonado de repositorios III
56. 56 egit: Clonado de repositorios IV
57. 57 egit: Clonado de repositorios V
58. 58 egit: Clonado de repositorios VI
59. 59 egit: Creando nuevo Branch I
60. 60 egit: Creando nuevo Branch II
61. 61 egit: Creando nuevo Branch III
62. 62 egit: Realizando merge entre dos ramas I
63. 63 egit: Realizando merge entre dos ramas II
64. 64 egit: Realizando merge entre dos ramas III
65. 65 egit: Realizando merge entre dos ramas IV
66. 66 egit: Subiendo branch local al servidor I
67. 67 egit: Subiendo branch local al servidor II
68. 68 egit: Borrando branch local
69. 69 egit: Trayendo branch del servidor a local I
70. 70 egit: Trayendo branch del servidor a local II
71. 71 egit: Trayendo branch del servidor a local III
72. 72 egit: Trayendo branch del servidor a local IV
73. 73 egit: Trayendo branch del servidor a local V
74. 74 egit: Borrando brach en el servidor I
75. 75  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. Sistemas de Integración continua
76. 76  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. Presentación Jenkins
77. 77  Jenkins puede descargarse desde http://jenkins-ci.org/  Instalar la aplicación jenkins.war en un servidor.  Acceder consola de Jenkins Instalación de Jenkins
78. 78  Acceder opción administrar Jenkins/Configuración del sistema Configuración básica de Jenkins I
79. 79  Configurar seguridad Configuración básica de Jenkins II
80. 80  Configurar JDK Configuración básica de Jenkins III
81. 81  Configurar Maven Configuración básica de Jenkins IV
82. 82  Configurar Mail Configuración básica de Jenkins V
83. 83  Instalar plugin de Git Integración Jenkins – Git I
84. 84  Configuración plugin de Git Integración Jenkins – Git II
85. 85  Crear nueva tarea Configuración tarea Jenkins I
86. 86 Configuración tarea Jenkins II
87. 87 Configuración tarea Jenkins III
88. 88  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. Importancia del Testing en Integración continua
89. 89  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. Emma
90. Madrid Avda. de Europa, 26 - Ática 5, 3ª Planta 28224 Pozuelo de Alarcón E-mail: info@paradigmatecnologico.com Teléfono: +34 91 352 59 42 Fax: +34 91 715 89 66